Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re: Good programmers and assembly language (very long)
Message-ID: <1991Apr12.182833.17825@mintaka.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
References: <2220@pdxgate.UUCP> <7227@harrier.ukc.ac.uk> <1991Apr12.123455.24220@zorch.SF-Bay.ORG>
Date: Fri, 12 Apr 91 18:28:33 GMT
Lines: 50

In article <1991Apr12.123455.24220@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>Not about to wade through Mike Rizzo's whole 435 article again at 1200
>baud to quote four lines, but the claim was made in an inclusion that
>"the quicksort programmer would have less need than an assembly games
>writer to make his program faster".
>
>This shows an incredible lack of knowledge of programming as a field of
>endeavor. Some of the most valuable products, with the most invested
>man-years, and at the highest prices (and profits) for sale in the
>business data processing market place are sort packages, and they sell
>based entirely on speed.  This is easy to confirm; just go pick up the
>latest copy of ComputerWorld, look for the full page sort package ads,
>and note the prominent position and size of the histograms comparing
>speed against the competitors' products.
>
>Why, you may ask, is speed so important in this field?  Because 75% of
>_all_ cpu cycles in business data processing are spent doing sorts.
>Shave off 1/15th of the time needed to run the sort, and you've added
>1/5th to the time available to do the rest of the job, and made the
>hardware 1/5th more productive.
>
>Write a faster sort and the world will pave your pathway with cold, hard
>cash.
>
>Kent, the man from xanth.
><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

  I agree with your post Kent, except for one important point. If Miranda
was ported to the Amiga, the library functions would be written in 
very quick assembler. For instance, most C libraries for the Amiga
have the QSort fnction written in optimized Asm. The only overhead
is the C function call. Still, _algorithms_ are still far more
important than minimal assembler optimizations. Check out the April
issue of BYTE. Dave Quick (Amigan) made a minor improvement to the old
bubblesort algorithm which makes it faster than a QSort!
  Also, there comes a time of diminishing returns where a 10% optimization
in speed doesn't speed up the application much. A major overhead in 
databases is the file system uses, and how to store records in the best
configuration possible to make lookup and searching fast. 

  Shaving off a few cycles in a QSort won't bring cold hard cash to your door.
Invent a totally new algorithm that no one thought of before and they
might. (Besides, you could patent it and make everyone else license it.
Although I don't like Software patents.)

--
+-----------------------------------------------------------------------------+
| rjc@gnu.ai.mit.edu   |   //  The opinions expressed here do not in any way  |
| uunet!tnc!m0023      | \X/   reflect the views of my self.                  |
+-----------------------------------------------------------------------------+