home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / sgi / 18541 < prev    next >
Encoding:
Text File  |  1993-01-06  |  4.1 KB  |  83 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!uimrl7.mrl.uiuc.edu!ercolessi
  3. From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
  4. Subject: Re: Indigo R4k/IBM 6k comparison
  5. References:  <8378@news.duke.edu>
  6. Message-ID: <C0GMqw.6LF@news.cso.uiuc.edu>
  7. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  8. Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
  9. Organization: MRL - UIUC
  10. Date: Thu, 7 Jan 1993 01:28:06 GMT
  11. Lines: 70
  12.  
  13. In article <8378@news.duke.edu>, rla@canctr.mc.duke.edu writes:
  14. |>Greetings.  We are considering a purchase of a set of 4 workstations to be
  15. |>linked together.  Objectives are mainly processing (number-crunching) power
  16. |>plus the ability to run the GCG DNA sequence analysis suite of programs.
  17. |>The two remaining candidates are SGI (R4000-based) vs. IBM RS6000s.
  18. |>
  19. |>Anyone with experience on both platforms, including service and reliability
  20. |>and UNIX performance, please let me know your thoughts.  Overall system
  21. |>speed is a major consideration.
  22.  
  23. I can perhaps say something on number-crunching, since we have run a
  24. few benchmarks in Trieste.  We do heavy computational physics there.
  25. *The results are very strongly application dependent*, much more than
  26. we expected.
  27.  
  28. We have found that the IBMs have a very good performance in linear
  29. algebra calculations, particularly with big-sized arrays.  For example,
  30. the 560 processor scores 84 Mflops in Linpack 1000x1000, which is
  31. indeed impressive.  HP and SGI are far behind, typically crawling around 
  32. 20 Mflops on this benchmark [these data can be obtained as a PostScript
  33. file by sending a mail to netlib@ornl.gov, containing the message
  34. 'send performance from benchmark'].  The case of DEC Alpha is
  35. a bit mysterious because it is reported to be 80 MFlops for the
  36. 3000-500 machine, but we could get only 11. In the other cases
  37. we were usually able to reproduce the table results.
  38. Moreover, the performance increases in the IBM when going from
  39. 100x100 to 1000x1000, while it typically decreases with the other 
  40. processors.
  41.  
  42. But on a classical molecular dynamics benchmark, the results are
  43. opposite!   {DEC,HP,SGI} are almost twice faster than the IBM
  44. offering in the same price range.
  45.  
  46. So we buy them all, for the desperation of our system manager,
  47. and run big electronic structure codes, doing mostly linear algebra
  48. or anyway very straightforward operations on huge loops, 
  49. on IBMs with plenty of memory and no graphics display, and classical 
  50. molecular dynamics, Monte Carlo and similar stuff on 32MB equipped 
  51. (or sometimes even 16MB) workstations of other manufacturers,
  52. which are IMHO also nicer for interactive work. 
  53.  
  54. Apparently, one of the key issues is the cache architecture:
  55. size and bandwidth.  The first code described above, doing linear
  56. algebra calculations, is very local in memory and uses a large
  57. and fast cache memory at its best.  In contrast, the second code
  58. is highly non-local (it has lots of indirect addressing and jumps
  59. in memory like hell), and probably gives a poor Megaflops rating
  60. in all cases.  Clearly, different design decisions have been made
  61. by the various teams.  HP and SGI seem to behave quite similarly.
  62.  
  63. Another issue giving a good Linpack rating for the IBM is the
  64. multiply-and-add instruction, where these two operations are
  65. done in a single machine cycle.  This is clearly exploited, since
  66. the 84 MFlops result is obtained on a 50 MHz machine.
  67. IBM put some carefully coded BLAS routine in their ESSL
  68. library.  Maybe that HP and SGI also have such an instruction,
  69. but it is not exploited by the compilers/libraries yet.
  70.  
  71. DISCLAIMER: I am a poor application programmer trying to
  72. understand these wonderful machines "on the field", and make
  73. the best choices in the market.  I really do not know what is behind the 
  74. scenes ... Any insight and further input is appreciated!
  75. And, of course, number crunching is not all, as anybody struggling
  76. to land with the 747 on that damned short runway knows ... :-)   
  77.  
  78. --
  79. Furio Ercolessi
  80. Materials Research Laboratory           |   Intl School for Advanced Studies
  81. Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
  82. furio@uiuc.edu                          |   furio@sissa.it
  83.