Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!tut.cis.ohio-state.edu!att!ihlpb!TSfR!usenet
From: usenet@TSfR.UUCP (usenet)
Newsgroups: comp.sys.atari.st
Subject: Re: Comment on PD/Shareware C compiler
Summary: Dhrystone isn't completely invalid, you know.
Message-ID: <539@TSfR.UUCP>
Date: 7 May 89 20:33:14 GMT
References: <1048@orbit.UUCP> <1471@atari.UUCP> <703@forty2.UUCP>
Reply-To: orc@TSfR.UUCP (David L. Parsons)
Followup-To: comp.sys.atari.st
Organization: This Space for Rent - Lisle, IL
Lines: 56
Expires:

In article <703@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes:
>In article <1471@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>> [Discussion of lousy Dhrystones for GCC]
>>                                              .....It is beaten by ALL
>>the other Atari C compilers I could find (Dhrystone 2.1), by a factor of
>>two or more in some cases.  This includes using -O, but no other
>>optimization options; some may pay, others aren't available (like
>>"no-function-cse").  .....
>>		..... For 68020 the code quality is not substantially
>>better: it doesn't beat MWC's 68000 code (both running on a 68020 (well,
>>030), obviously).  And without the 68030's cache enabled, GCC's 020 is
>>worse than all but Aztec's +P (large code, data, and ints) 68000 code. 
>
>If you want to limit 
>all your programs to 32kB data structures and 16 bit ints, please don't
>let us stop you. (BTW did you try real programs or did you just try 
>Drhystone [sic] ????)

  If the Dhrystone was completely invalid, it wouldn't be used.  10-15%
variance can probably be ignored, but when a compiler turns in results
that are half of the other compilers, it's probably an indication that
something is badly damaged in that compiler.  And if the '020 code it
produces doesn't work as well as someone else's '000 code on a '020,
well, that's one sick puppy.

  `Limited' by 16-bit ints && 32k data structures?  Hmm, that's a novel
idea.  I'll be on the lookout for those `limits' in the future.

>>My point is that this port of GCC stinks. ....
>                       ^^^^
>As to the quality of the 68020 code produced (I've used/am using gcc on
>other machines) I can assure you that gcc is pretty good...

 Pity the ST is only a 68000.  If Gnu CC is designed for a '020, perhaps
that explains the abominable benchmarks when it's chopped up for the ST.
However, I don't see any connection between your use of GCC on other
machines (presumably '020s?) and the awful performance reported by apratt.

>>These are the ST timings I got for Dhrystone 2.1.
>Using ONE number to classify a compiler is not a very good idea...

 Yes, but if that one number is *so* substandard, it's a good indication
that _something_ is *NOT* *WORKING* in that implementation.

>... just as well claim that mwc and Turbo C  are broken because they fail on 
>one moderately complex and long macro (in Flex).

 Maybe so.  But the compiled code works quickly, which is one of the _really_
important things for some of us. (It's easier to write a new cpp than it is
to write a new code generator.)  Alcyon C chokes on complex expressions that
GCC will probably digest without a quiver, but if the code coming out of GCC
runs half as fast as Alcyon, I'll gladly live with having to `fix' the source
code for Alcyon.

   -david parsons
   -orc@pell.uucp