home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / benchmar / 1401 < prev    next >
Encoding:
Text File  |  1992-09-09  |  3.0 KB  |  60 lines
  1. Newsgroups: comp.benchmarks
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!convex!convex!patrick
  3. From: Patrick F. McGehearty <patrick@convex.COM>
  4. Subject: Re: Surprised:gcc&dhryston benchmarks
  5. Originator: patrick@mozart.convex.com
  6. Sender: usenet@news.eng.convex.com (news access account)
  7. Message-ID: <1992Sep10.165714.9303@news.eng.convex.com>
  8. Date: Thu, 10 Sep 1992 16:57:14 GMT
  9. Reply-To: patrick@convex.COM (Patrick F. McGehearty)
  10. References: <1992Sep10.131908.17807@ntuix.ntu.ac.sg>
  11. Nntp-Posting-Host: mozart.convex.com
  12. Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
  13. X-Disclaimer: This message was written by a user at CONVEX Computer
  14.               Corp. The opinions expressed are those of the user and
  15.               not necessarily those of CONVEX.
  16. Lines: 42
  17.  
  18. In article <1992Sep10.131908.17807@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
  19. ...
  20. >Conclusion:
  21. >dhryston 1.1 is not yet useless because it actually gives a reasonable
  22. >processor speed indication for small programs. Sometimes this is what we
  23. >want.
  24. >
  25. In another posting I give some reasons which Dhrystone has the potential
  26. to be misleading.  Those comments were for Dhrystone-2.1.  Dhrystone-1.1 is
  27. even worse.  A sufficiently advanced optimizing compiler can eliminate
  28. almost all of the code in Dhrystone-1.1.  What do the measurements mean
  29. then?  Nothing interesting.
  30.  
  31. >My recommendations to Spec Mark consortium is to find small programs that
  32. >characterise a computer system characteristics, e.g. cache, RAM, disk,
  33. >Character, Graphic, serial, interrupt-response etc.
  34. >
  35. >Then for each software, what portions of those characteristics do they 
  36. >consume. Cross-correlation with predicted results using those basic 
  37. >characteristics for a software, and the actual results of running user 
  38. >software should be done, to validate the "usefulness of those programs".
  39. >
  40. >Some of those small programs are 
  41. >dhryston for integer small programs,
  42. >lorenze for floating point small programs,
  43. >iozone for portable I/O,
  44. >
  45. lorenze can be extremely misleading for predicting floating point
  46. performance.  As written, there is a subroutine call for every few
  47. floating point operations.  If you have a compiler which inlines
  48. that subroutine, AND you use the right options to get that inlining,
  49. your performance will be dramatically different (a factor of 2 on some
  50. machines) than if you don't inline the results.  A factor of 2 is bit more
  51. than should be waved off as background noise.  If you must use something
  52. that simple, try Dongarra's 100x100 Linpack benchmark (there are C versions
  53. floating around).  Results are reported regularly for a long list of
  54. machines, and scrutinized by many people.  Much better (but also much more
  55. work to get running) is to use the Perfect Club benchmarks. Another
  56. alternative would be to write some loops for common floating operations such
  57. as matrix multiply, correlation, sum reduction, etc.  Do not include
  58. unnecessary subroutine calls in the inner loops as that just causes the
  59. program to be measuring something besides floating point performance.
  60.