home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / benchmar / 1911 < prev    next >
Encoding:
Text File  |  1993-01-05  |  11.4 KB  |  285 lines
  1. Newsgroups: comp.benchmarks
  2. Path: sparky!uunet!think.com!ames!data.nas.nasa.gov!amelia.nas.nasa.gov!eugene
  3. From: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
  4. Subject: [l/m 4/7/92] Performance metrics (5/28)    c.be FAQ
  5. Keywords: who, what, where, when, why, how
  6. Sender: news@nas.nasa.gov (News Administrator)
  7. Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA
  8. Date: Tue, 5 Jan 93 12:25:12 GMT
  9. Message-ID: <1993Jan5.122512.23579@nas.nasa.gov>
  10. Reply-To: eugene@amelia.nas.nasa.gov (Eugene N. Miya)
  11. Lines: 272
  12.  
  13. 5    Performance Metrics                    <This panel>
  14. 6    Temporary scaffold of New FAQ material
  15. 7    Music to benchmark by
  16. 8    Benchmark types
  17. 9    Linpack
  18. 10
  19. 11    NIST source and .orgs
  20. 12    Benchmark Environments
  21. 13    SLALOM
  22. 14
  23. 15    12 Ways to Fool the Masses with Benchmarks
  24. 16    SPEC
  25. 17    Benchmark invalidation methods
  26. 18
  27. 19    WPI Benchmark
  28. 20    Equivalence
  29. 21    TPC
  30. 22
  31. 23
  32. 24
  33. 25    Ridiculously short benchmarks
  34. 26    Other miscellaneous benchmarks
  35. 27
  36. 28    References
  37. 1    Introduction to FAQ chain and netiquette
  38. 2
  39. 3    PERFECT
  40. 4
  41.  
  42.  
  43. Performance/benchmark metric terminology
  44.  
  45. The usual important quote is:
  46.     What's important is the time it takes to solve MY problem.
  47. This does not help the architect designing tne next machine.
  48. It is a arrogant closed minded, Gestaltist statement which conflicts
  49. with the analytic/reductionist needs for science.
  50.  
  51. Synthetic problems/benchmarks have some if limited value.
  52. We walk before we run, and we crawl before we walk.  Similarly,
  53. right now, there is more benchmarking noise than signal.
  54.  
  55. Perhaps the only, certainly best measure, is the second (time):
  56. one of the best studied metrics see the atomic clocks of the NIST.
  57. Subject to relativistic effects: the Lorentz time contraction.
  58. Don't laugh, this is becoming more important at the pico-second level
  59.  
  60. Less reliable measures include:
  61.  
  62. MIP, GIP, TIP    :
  63. MIPS, GIPS, TIPS:    Million (Giga, billions; tera, trillion) Instructions
  64.     Per Second
  65.     :    Meaningless Indicator of Performance
  66.     :    "Marketing's" Indicator of Performance
  67. What's an "instruction?"
  68.     An instruction is an event.  It is frequently a minunt change in the
  69.     state of a CPU (and the computer).  Frequently, an instruction if
  70.     synonymous with the clock rate of a machine: that ignores instructions
  71.     requiring more than one clock pulse tick to execute.
  72.  
  73.     A common fallacy by naive benchmarkers is that a CPU determines the
  74.     speed of a computation.  This is frequently false.  The people in
  75.     the know these days understand 
  76.     Amdahl's "other law:"
  77.     1 MIPS for each 1 MB main memory at 1 MB/S transfer to disk
  78.  
  79. MFLOPS, GFLOPS, TFLOPS: Million (Giga, billions; tera, trillion) Floating-Point
  80.     Operations Per Second
  81.     : The measure ignores non-floating-point instructions.  Particularly
  82.     bad for numeric codes transitioning from 2-D to 3-D since additional
  83.     time is required for array address calculation, and for algorithms
  84.     requiring big non-numeric steps like matrix transposition.
  85.     : the original program name for Frank McMahon's Livermore Loops
  86.     program.
  87.     : one of the metrics used by Dongarra's LINPACK benchmark.
  88.  
  89. LIPS, KLIPS, MLIPS: Logical "inferences" Per Second --
  90.     from the Logic Programming community (Gabriel LISP benchmarks).
  91.     Also available in Prolog (Evan Tick).  LIPS roughly correspond to
  92.     "calls per second" for very simple predicates.
  93.  
  94. Packets Per Second:    Unit of measure used by the networking, communications
  95.     community.  Sometimes useful.
  96.     : What do they do make consistent packets?
  97.  
  98. MHz, GHz, Bits per Second, Bytes per Second, Words per Second:
  99.     : Frequently used to mismeasure the performance of computer networks
  100.     like Ethernet (tm).  It confuses the base band carrier frequency
  101.     with the data trasnfer rate.  It's not truth, but not complete false.
  102.     : Also sometimes call Null or Wait instructions.
  103.  
  104. TPS    :    Transactions per second, agree on metric by transaction
  105.     processing council.
  106.     : What's a transaction?
  107.  
  108. Stones    : An arbitrary unit of computation based on the Whetstone
  109.     (or Dhrystone or other *stone) which is subject to the influences
  110.     like compiler optimization or cache metrics.
  111.     : What's a transaction?
  112.  
  113. Normalized metrics
  114.  
  115. SPECmark: A normalized metric based on the performance against a
  116.     DEC VAX-11/780.  Based on a SPEC workload on a 780 under glass.
  117.  
  118. Speed up:
  119.  
  120. Efficiency:
  121.  
  122. Our problems aren't counting seconds (intervals or days), it's not counting
  123. instructions, operations, floating point operations.
  124.  
  125. Events counts like instructions or operations are best done by non-instrusive
  126. instruction/operating counting hardware.  These are expensive to say the least.
  127. Software profilers/event counters are also some times useful, but they are
  128. subject to optimization.
  129.  
  130. We need to distingush "virtual" operations or instructions from
  131. real or actual instructions.
  132.  
  133. Prefixes:
  134. kilo, mega, giga, tera, eka, peta,
  135. milli, micro, nano, pico, femto,
  136.  
  137.  
  138. Performance metrics are unlike conventional mathematics.
  139. You can't make mathematical inferences (excepting "guaranteed not to
  140. exceed numbers"), you can't apply all mathematical operators.  The basis
  141. for metric theory is that for a metric space X and a metric function d()
  142. which maps elements of X to the real number system, then 
  143.     a)
  144.     b) 
  145.     c) d(A + B) <= d(A) + d(B) [triangle inequality]
  146.  
  147. You might have a benchmrk sized for 128 elements.  A program might not test
  148. well if it used 127 or 129 elements instead.  It is not possible in
  149. infer or interpolate between values because of benchmarking "gotchas."
  150. This is especially bad when dealing with powers of two: an artifact
  151. of computer architecture, but sometimes also due to software (in a base-10
  152. world).
  153.  
  154. Mathematics derives a large portion of its power because of assumptions of
  155. continuity.  Computers are very discrete objects.  What works for case n might
  156. not work for case n-1 or n+1 (vector architectures for instance).
  157. Some interesting thing are learned by simply modifying the size of a benchmark
  158. by one (remember Kernighan and Plauger: beware off-by-1 errors).
  159.  
  160. Can you even be assured of consistent measures?
  161. Most benchmarks try to run their tests in standalong conditions to
  162. attain consistency.  This is an artifact of not being able to have a
  163. non-intrusive measurement environment.
  164.  
  165. Measurement issues:
  166. 1) Reproducibility: first and foremost.  You must be able to reproduce
  167.    performance.
  168. 2) Accuracy and precision.  Tough because of human limits.
  169. 3) Resolution.  Details sometimes count.
  170. 4) History (memory).
  171. 5) 
  172.  
  173. Another important: measurement tools and environments
  174. What are some nice ones:
  175. Simple ones (non-standard) software
  176. Several: 'arch' name architecture,
  177. Cray: flotrace, hpm (hardware and software actually), others
  178. SGI/MIPS: gr_osview, ancillary: hinv (hardware inventory), pixie
  179. Convex: syspic,
  180. Obsolete ones: gprof, prof (your names may not vary, but the tools does,
  181.     watch for name collision)
  182.  
  183. Other useful tools should be reported.  Why?  Because most people do
  184. not get reasonable experience with the various kinds of tools out there
  185. to understand their advantages, drawbacks, etc.
  186.  
  187. Beware of the graphical tools.  They can deceive you.  All performance
  188. monitoring tools can deceive you.  Use them carefully.
  189.  
  190. Example of a good/useful tool from a 'Class A' measurement environment.
  191. Sample Cray Research, Inc. Hardware Performance Monitor output:
  192.  
  193. hpm VERSION 1.3
  194.  
  195.    (c) COPYRIGHT CRAY RESEARCH, INC.
  196.  
  197.     UNPUBLISHED -- ALL RIGHTS RESERVED UNDER
  198.     THE COPYRIGHT LAWS OF THE UNITED STATES
  199.  
  200.  STOP  (called by EMPTY )
  201.  CP: 0.001s,  Wallclock: 0.038s,  0.2% of 8-CPU Machine
  202.  HWM mem: 97679, HWM stack: 2048, Stack overflows: 0
  203. Group 0:  CPU seconds   :       0.00      CP executing     :         197638
  204.  
  205. Million inst/sec (MIPS) :      44.47      Instructions     :          52730
  206. Avg. clock periods/inst :       3.75
  207. % CP holding issue      :      42.57      CP holding issue :          84134
  208. Inst.buffer fetches/sec :       0.77M     Inst.buf. fetches:            913
  209. Floating adds/sec       :       0.21M     F.P. adds        :            246
  210. Floating multiplies/sec :       0.23M     F.P. multiplies  :            267
  211. Floating reciprocal/sec :       0.05M     F.P. reciprocals :             54
  212. I/O mem. references/sec :       0.22M     I/O references   :            256
  213. CPU mem. references/sec :      14.58M     CPU references   :          17287
  214.  
  215. Floating ops/CPU second :       0.48M
  216.  STOP  (called by EMPTY )
  217.  CP: 0.001s,  Wallclock: 0.002s,  4.2% of 8-CPU Machine
  218.  HWM mem: 97679, HWM stack: 2048, Stack overflows: 0
  219.  
  220. Group 1:  CPU seconds  :        0.00119  CP executing:         198071
  221.  
  222.   Hold issue condition              % of all CPs       actual # of CPs
  223. Waiting on semaphores              :   0.14                       284
  224. Waiting on shared registers        :   0.00                         0
  225. Waiting on A-registers/funct. units:   9.35                     18520
  226. Waiting on S-registers/funct. units:  27.98                     55418
  227. Waiting on V-registers             :   1.35                      2671
  228. Waiting on vector functional units :   0.00                         9
  229. Waiting on scalar memory references:   0.56                      1101
  230. Waiting on block memory references :   1.86                      3685
  231.  STOP  (called by EMPTY )
  232.  CP: 0.001s,  Wallclock: 0.002s,  4.4% of 8-CPU Machine
  233.  HWM mem: 97679, HWM stack: 2048, Stack overflows: 0
  234.  
  235. Group 2:  CPU seconds   :        0.00121     CP executing  :          201785
  236.  
  237. Inst. buffer fetches/sec   :       0.75M  total fetches    :             913
  238.                                           fetch conflicts  :            5265
  239. I/O memory refs/sec        :       0.00M  actual refs      :               0
  240.     avg conflict/ref   0.00:              actual conflicts :             100
  241. Scalar memory refs/sec     :       5.51M  actual refs      :            6668
  242. Block memory refs/sec      :       8.77M  actual refs      :           10619
  243. CPU memory refs/sec        :      14.28M  actual refs      :           17287
  244.     avg conflict/ref   0.15:              actual conflicts :            2668
  245.   CPU memory writes/sec    :       8.66M  actual refs      :           10479
  246.   CPU memory reads/sec     :       5.62M  actual refs      :            6808
  247.  STOP  (called by EMPTY )
  248.  CP: 0.001s,  Wallclock: 0.030s,  0.2% of 8-CPU Machine
  249.  HWM mem: 97679, HWM stack: 2048, Stack overflows: 0
  250.  
  251. Group 3:  CPU seconds  :        0.00119     CP executing:         198445
  252.  
  253.  (octal) type of instruction     inst./CPUsec      actual inst.  % of all inst.
  254. (000-017)jump/special           :       5.30M             6315     11.98
  255. (020-077)scalar functional unit :      33.24M            39578     75.07
  256. (100-137)scalar memory          :       5.60M             6668     12.65
  257. (140-157,175)vector integer/log.:       0.01M               14      0.03
  258. (160-174)vector floating point  :       0.00M                2      0.00
  259. (176-177)vector load and store  :       0.12M              141      0.27
  260.  
  261.   type of operation                ops/CPUsec       actual ops   avg. VL
  262. Vector integer&logical          :       0.12M              138      9.86
  263. Vector floating point           :       0.19M              232    116.00
  264. Scalar functional unit          :      33.24M            39578
  265. =====
  266.  
  267. Im memoriam to Rear Adm. Grace Murray Hopper, for all the "nano seconds"
  268. and "pico seconds" she passed out (30 cm/1 ft copper wires or salt grains).
  269. She will be missed.
  270.  
  271.                    ^ A  
  272.                 s / \ r                
  273.                m /   \ c              
  274.               h /     \ h            
  275.              t /       \ i          
  276.             i /         \ t        
  277.            r /           \ e      
  278.           o /             \ c    
  279.          g /               \ t  
  280.         l /                 \ u
  281.        A /                   \ r
  282.         <_____________________> e   
  283.                 Language
  284.  
  285.