Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!texsun!pitstop!sundc!seismo!uunet!mcvax!cernvax!ethz!forty2!poole From: poole@forty2.UUCP (Simon Poole) Newsgroups: comp.sys.atari.st Subject: Re: Comment on PD/Shareware C compiler Message-ID: <715@forty2.UUCP> Date: 10 May 89 11:55:56 GMT References: <1048@orbit.UUCP> <1471@atari.UUCP> <703@forty2.UUCP> <539@TSfR.UUCP> Reply-To: poole@forty2.UUCP (Simon Poole) Organization: Exp. Physics University Zuerich Lines: 89 In article <539@TSfR.UUCP> orc@TSfR.UUCP (David L. Parsons) writes: >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] ......... >>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% If 99% of the people that use dhrystone don't even know what it mesures, how are they to know if it's valid or invalid???? >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, ^^^^^^^^^^^^^^^^^^ `small model` code (16 bits integers) is faster on a 020, regardless if you are generating 020 or 000 code (this is not quite true for stuff that's in the cache). >well, that's one sick puppy. I think it would be instructive for you to have a look at the actual dhrystone code. To show why dhrystone results shouldn't be overrated, here a profile of dhrystone 1.1 (sorry, didn't have the sources of 2.1 handy): granularity: each sample hit covers 2 byte(s) for 0.01% of 125.57 seconds flat profile: %time the percentage of the total running time of the program used by this function. cumsecs a running sum of the number of seconds accounted for by this function and those listed above it. seconds the number of seconds accounted for by this function alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. %time cumsecs seconds calls name 18.3 23.04 23.04 1 _Proc0 15.1 42.02 18.98 500002 _strcpy 14.1 59.74 17.72 500000 _Proc1 13.9 77.18 17.44 500000 _strcmp 7.5 86.66 9.48 500000 _Proc8 6.1 94.31 7.65 500000 _Func2 4.8 100.38 6.07 1500000 _Func1 4.7 106.23 5.85 1500000 _Proc7 4.0 111.26 5.03 500000 _Proc6 3.9 116.15 4.89 500000 _Proc3 2.6 119.42 3.27 500000 _Proc2 1.7 121.53 2.11 500000 _Proc4 1.7 123.62 2.09 500000 _Func3 1.5 125.56 1.94 500000 _Proc5 [rest of profile deleted] As you can see a good 30% of the time is spent in the libary routines strcpy and strcmp (this was run on a machine with assembler strcpy and strcmp), so bad/good dhrystone ratings do not HAVE to be representive of the actual code generated. One way to get very high dhrystone ratings is to make strcpy and strcmp compiler builtins, if the compiler is smart enough it can even turn the strcpy in to a block move. If Allan was running dhrystone with the first set of libary routines distributed with the Atari gcc port, it's no wonder he got so bad results (in particular if he didn't at least recompile them with the -fomit-frame-pointer flag). -- ---------------------------------------------------------------------------- Simon Poole Due to a new job these addresses will be going away after the 1. of June! UUCP: ...mcvax!cernvax!forty2!poole BITNET: K538915@CZHRZU1A