home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / sgi / 18554 < prev    next >
Encoding:
Text File  |  1993-01-07  |  4.3 KB  |  89 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!news.udel.edu!perelandra.cms.udel.edu!mccalpin
  3. From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
  4. Subject: Re: Indigo R4k/IBM 6k comparison
  5. Message-ID: <C0HEGt.4wv@news.udel.edu>
  6. Sender: usenet@news.udel.edu
  7. Nntp-Posting-Host: perelandra.cms.udel.edu
  8. Organization: College of Marine Studies, U. Del.
  9. References: <8378@news.duke.edu> <C0GMqw.6LF@news.cso.uiuc.edu>
  10. Date: Thu, 7 Jan 1993 11:26:53 GMT
  11. Lines: 76
  12.  
  13. In article <C0GMqw.6LF@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
  14. >In article <8378@news.duke.edu>, rla@canctr.mc.duke.edu writes:
  15. >|>The two remaining candidates are SGI (R4000-based) vs. IBM RS6000s.
  16.  
  17. >[details deleted]
  18. >Apparently, one of the key issues is the cache architecture:
  19. >size and bandwidth.  The first code described above, doing linear
  20. >algebra calculations, is very local in memory and uses a large
  21. >and fast cache memory at its best.  In contrast, the second code
  22. >is highly non-local (it has lots of indirect addressing and jumps
  23. >in memory like hell), and probably gives a poor Megaflops rating
  24. >in all cases.  Clearly, different design decisions have been made
  25. >by the various teams.  HP and SGI seem to behave quite similarly.
  26.  
  27. The LINPACK benchmarks do indeed use the cache well on all the 
  28. machines.  This allows IBM's faster FPU (2 FP OPs/cycle vs about
  29. 0.4 FP OPs/cycle on the MIPS chip) to stay busy.
  30.  
  31. However, one does not need to re-use the data in cache to get good
  32. performance -- just using everything that is fetched (i.e. use strides
  33. of 1 through memory) is enough to get the IBM to outperform the other
  34. vendors, although it will not reach the MFLOPS levels of the LINPACK
  35. 1000x1000 case.   This is consistent with the quoted results on the
  36. relative speeds for the second set of benchmarks mentioned, which 
  37. move through memory randomly.
  38.  
  39. Here is a partial set of results for a finite difference ocean model
  40. that uses exclusively unit strides through memory, but is definitely
  41. not cacheable.  The full set of results is available by anonymous ftp
  42. from perelandra.cms.udel.edu in bench/qgbox/.
  43.  
  44. Note that the obsolete IBM RS/6000-320 is roughly the same speed as
  45. the R4000 machines.  The new 580/980 IBMs should be roughly 3 times
  46. as fast as current R4000's.
  47.  
  48. Machine        Time (1) MFLOPS       Date        Notes    SPECfp92       MFLOPS/
  49.         seconds                               SPECfp92
  50. ------------------------------------------------------------------------------
  51. Cray C90, 1 cpu       17.8  396.4     92.12.09    (2,16)      -          -
  52. Cray Y/MP, 1 cpu   42.7     165.5     92.12.09    (2)      -          -
  53. IBM RS/6000-950      303      23.6   92.12.04    (12)     81.8        0.289
  54. DEC 3000-500 AXP  350      20.4     92.12.08    (10)    126.0        0.182
  55. IBM RS/6000-530H  388      18.4   92.12.04    (4,11)     57.7        0.319
  56. HP-9000/730      590      12.1     92.12.09    (15)     75.0        0.161
  57. SGI R4000 Indigo  731       9.8     92.12.04    (5)    ~61        0.160
  58. SGI Crimson      817       8.7   92.12.03       (3)     63.4        0.137
  59. IBM RS/6000-320      828       8.6   92.09.23    (14)    ~31.5       0.273
  60. HP-9000/720      872       8.2   92.12.04       (4)     58.2        0.148
  61. HP-9000/710     1041       6.9   92.12.05       (4)     31.6        0.218
  62. SparcClassic     1046       6.8     92.12.07    (6)     21.0       0.323
  63. SparcStation2     2062       3.5     92.12.07    (7)     21.8        0.161
  64. SGI 4D/25     4691       1.5   92.09.23        ~10.        0.150
  65. ------------------------------------------------------------------------------
  66.  
  67. (1) The above timings are user times only.
  68. (2) Inline tridsolve() by compiler directive.
  69.     Used different versions of advect2() and delsq5().
  70. (3) charlie@kestrel.tamu.edu, f77 -O -mips2
  71. (4) olin@cheme.tn.cornell.edu, f77 -O
  72. (5) fisher@ivy.dt.navy.mil, f77 -O2 -mips2
  73. (6) daniel.nelsen@Eng.Sun.COM, SC2.0.1-f77 -dalign -cg92 -O4
  74. (7) daniel.nelsen@Eng.Sun.COM, SC2.0.1-f77 -dalign -cg89 -O4
  75. (10) ecf_stbo@jhuvms.hcf.jhu.edu, VMS AXP V1.0; Dec fortran V6.0.,
  76.      (specifically "EV6.0-289-24AG") F77/optimize
  77.     No writes to fort.11 or fort.12
  78. (11) The SPECfp92 number here is out-of-date.
  79. (12) jbs@watson.ibm.com, xlf 2.3.
  80. (14) mccalpin@perelandra.cms.udel.edu, xlf 1.2
  81. (15) bt@irfu.se, FFLAGS = +OP2 +OS +O3 -Wl,-a,archive -WP,-cachesize=256,
  82.     -arclimit=5000,-aggressive=a,-vectorize,-optimize=4
  83. (16) cmg@magnet.cray.com, used qgbox.cray.f, inlined trid_solve
  84. -- 
  85. --
  86. John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
  87. Assistant Professor                     mccalpin@brahms.udel.edu
  88. College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
  89.