Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!claris!outpost.UUCP!peirce
From: peirce@outpost.UUCP (Michael Peirce)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Increment (Was Re: Pascal deficiency)?
Message-ID: <0B010004.er575b@outpost.UUCP>
Date: 24 Dec 90 05:33:02 GMT
Reply-To: peirce@outpost.UUCP
Organization: Peirce Software
Lines: 44
X-Mailer: uAccess - Mac Release: 1.0.3


In article <47576@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) writes:
> By the way, I also tried out gC on a much larger program. Compiled
> under MPW 3.2 C, this program was 83K long. Under gC, the program
> was 81K. Either:
> 
> a) MPW C is better than we thought
> b) gC is not as good as we thought
> c) the author of the program took advantage of constructs that lent
>    themselves to being compiled better, no matter what the compiler was
>    (I know that this alternative is not the case, though)
> d) or the example I chose just happened to be a bad example ("bad", that
>    is, for anyone trying to show that MPW C is a crummy compiler).

I'm no compiler expert (and it probably shows :-), but I think we're
barking up the wrong trees with our simple examples.

Really good compilers shine in the complex programs.  They look at
the context of big complex programs and do wonderous things.  

I remember working with some DEC compilers on VAX/VMS that did such
things.  One example was some very fancy automatic inlining functions, 
then it optimizing the result down to very a few instructions.  It allowed 
programmers to write very abstract code and still get the efficency some 
people only believe you get in C.

If a compiler can't figure out that i++ and i=i+1 aren't the same
thing, this is just plan stupid.  Now, I realize that some compilers
are still fairly stupid and we need to pay attention to details in
certain critical pieces of code to squeeze the most out our Macs,
but someday the compilers on the Mac will catch up with the rest of
the industry. (please please please!)

Another point to keep in mind is that all the time spend hand tweeking
can often be better spent rethinking the algorithm in the first place.
Very efficient implementations of poor algorithms will be slower than
fair implementations of superior algorithms.

-- michael, shooting is mouth off again...


--  Michael Peirce         --   {apple,decwrl}!claris!outpost!peirce
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California 95117
--           & Consulting  --   (408) 244-6554, AppleLink: PEIRCE