home *** CD-ROM | disk | FTP | other *** search
/ Meeting Pearls 3 / Meeting_Pearls_III.iso / Pearls / bench / Dhrystone / source / DhrystoneSRC.lha / dhry / clarify.doc next >
Text File  |  1990-03-18  |  3KB  |  75 lines
  1. CLARIFICATION
  2. There seems to have been a great deal of confusion over what this
  3. benchmark measures, and how to use these results.  Let me try to clarify
  4. this:
  5.  
  6.     1) DHRYSTONE is a measure of processor+compiler efficiency in
  7.        executing a 'typical' program.  The 'typical' program was
  8.        designed by measuring statistics on a great number of
  9.        'real' programs.  The 'typical' program was then written
  10.        by Reinhold P. Weicker using these statistics.  The
  11.        program is balanced according to statement type, as well
  12.        as data type.
  13.  
  14.     2) DHRYSTONE does not use floating point.  Typical programs don't.
  15.  
  16.     3) DHRYSTONE does not do I/O.  Typical programs do, but then
  17.        we'd have a whole can of worms opened up.
  18.  
  19.     4) DHRYSTONE does not contain much code that can be optimized
  20.        by vector processors.  That is why a CRAY doesn't look real
  21.        fast, they weren't built to do this sort of computing.
  22.  
  23.     5) DHRYSTONE does not measure OS performance, as it avoids
  24.        calling the O.S.  The O.S. is indicated in the results only
  25.        to help in identifying the compiler technology.
  26.  
  27.     6) DHRYSTONE is not perfect, but is a hell of a lot better than
  28.        the "sieve", or "SI".
  29.  
  30.     7) DHRYSTONE gives results in dhrystones/second.  Bigger
  31.        numbers are better.  As a baseline, the original IBM PC
  32.        gives around 300-400 dhrystones/second with a good compiler.
  33.        The fastest machines today are approaching 100,000.
  34.  
  35. If somebody asked me to pick out the best machine for the money, I
  36. wouldn't look at just the results of DHRYSTONE.  I'd probably:
  37.  
  38.     1) Run DHRYSTONE to get a feel for the compiler+processor
  39.        speed.
  40.     2) Run any number of benchmarks to check disk I/O bandwidth,
  41.        using both sequential and random read/writes.
  42.     3) Run a multitasking benchmark to check multi-user response
  43.        time.  Typically, these benchmarks run several types of
  44.        programs such as editors, shell scripts, sorts, compiles,
  45.        and plot the results against the number of simulated users.
  46.     4) If appropriate for the intended use, run something like
  47.        WHETSTONE, to determine floating point performance.
  48.     5) If appropriate for intended use, run some programs which do
  49.        vector and matrix computations.
  50.     6) Figure out what the box will:
  51.         - cost to buy
  52.         - cost to operate and maintain
  53.         - be worth when it is sold
  54.         - be worth if the manufacturer goes out of business
  55.     7) Having done the above, I probably have a hand-full of
  56.        machines which meet my price/performance requirements.
  57.        Now, I find out if the applications programs I'd like
  58.        to use will run on any of these machines.  I also find
  59.        out how much interest people have in writing new software
  60.        for the machine, and look carefully at the migration path
  61.        I will have to take when I reach the (inevitable) limits
  62.        of the machine.
  63.  
  64. To summarize, DHRYSTONES by themselves are not anything more than
  65. a way to win free beers when arguing 'Box-A versus Box-B' religion.
  66. They do provide insight into Box-A/Compiler-A versus Box-A/Compiler-B
  67. comparisons.
  68.  
  69.             Rick Richardson
  70.             PC Research, Inc.
  71.             (201) 389-8963 (9-17 EST)
  72.             (201) 542-3734 (7-9,17-24 EST)
  73.             ...!uunet!pcrat!rick    (normal mail)
  74.             ...!uunet!pcrat!dry2    (results only)
  75.