Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!chianti!shane
From: shane@chianti.cc.umich.edu (Shane Looker)
Newsgroups: comp.sys.mac
Subject: Re: Benchmarking C Compilers (was Re: LightspeedC 3.0 Review (long))
Summary: Compile speed vs. Optimization is a trade off.
Keywords: Lightspeed C, gcc, Dhrystones
Message-ID: <583@mailrus.cc.umich.edu>
Date: 21 Jul 88 19:58:11 GMT
References: <76000259@p.cs.uiuc.edu> <4990@husc6.harvard.edu> <3133@Portia.Stanford.EDU>
Sender: usenet@mailrus.cc.umich.edu
Reply-To: shane@um.cc.umich.edu (Shane Looker)
Organization: University of Michigan Computing Center, Ann Arbor
Lines: 30


[So much discussion deleted you should thank me.]


>Unfortunately, on the purely Macintosh level, Lightspeed C, at 2500-2900
>Dhrystones, has quite a way to go before it matches an established optimizing
>compiler like gcc (sorry Rich).  Of course you can always argue that the
>Mac OS is quite a bit different than A/UX.  On the more positive side,
>Lightspeed C does do about as well as the standard AT&T cc compiler (which I
>assume was running in its optimizing mode).
>
>-Michael Wang


What all of you seem to be forgetting (or not realizing, or ignoring, or...)
is that Lightspeed C is optimized for fast COMPILE.  In a compiler you 
can have fast compilation or highly optimized code generation.  Not both.
LSC does not do peephole optimization either.  (I've seen a trivial case 
in LSC which could have been 6 instrucions, instead it was 10.  The code 
kept loading a register with the same value.  Acerbic comments on C's lack
of 'with' style construct inserted here.)

MPW is a slow compiler which has tighter optimization.  I know that.  I use
LSC because of the development time difference.

All we need to do is get Mike Kahl to put a separate optimization switch in
so you can have a slow final compile which has tight code :-)  (I'd actually
love this, but it would probably mean writing an entire second compiler.)

Shane Looker
Looker@um.cc.umich.edu