home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8877 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  1.6 KB
  1. Xref: sparky comp.arch:8877 comp.benchmarks:1299
  2. Newsgroups: comp.arch,comp.benchmarks
  3. Path: sparky!uunet!infonode!ingr!capalo!quintus!quintus!ludemann
  4. From: ludemann@quintus.com (Peter Ludemann)
  5. Subject: Re: MIPS ratings go up; faith in Dhrystone persists.
  6. Message-ID: <1992Aug12.231534.5843@quintus.com>
  7. Sender: news@quintus.com (USENET news account)
  8. Nntp-Posting-Host: ebisu
  9. Organization: Quintus Corporation, Palo Alto, CA
  10. References:  <1992Aug10.165958.16152@sinix.UUCP>
  11. Date: Wed, 12 Aug 1992 23:15:34 GMT
  12. Lines: 20
  13.  
  14. In article <1992Aug10.165958.16152@sinix.UUCP>, weicker@sinix.UUCP (Reinhold Weicker) writes:
  15. > 
  16. > Also, I must add that Dhrystone version 2.1 is not fool-proof either:
  17. > If a compiler compiles both compilation units together (not intended
  18. > for Dhrystone, but some compilers have such a switch), and does
  19. > excessive constant propagation (between procedures), it can determine
  20. > the whole flow of computation at compile time, and pre-compute the
  21. > output.
  22.  
  23. Indeed; I was caught by this when I tried comparing the gcc v2 compiler
  24. versus IBM's xlc on the RS/6000.  At first, it seemed that gcc was faster,
  25. but then it turned out that IBM's compiler was optimizing away the dummy
  26. timing loops, so the correction factor for loop overhead was coming out
  27. wrong.  I have heard of "hardened Dhrystones" to avoid such problems, but
  28. I suspect that each new optimizing compiler will require re-hardening.
  29. If we could somehow go through all the ftp sites and blow away all old
  30. Dhrystone sources, we might find a bit more truth in advertising ...
  31.  
  32. -- 
  33.     Peter Ludemann  +1-415-813-3800  ludemann@quintus.com
  34.