🚀 go-pugleaf

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