home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8180 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  1.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!sun-barr!male.EBay.Sun.COM!exodus.Eng.Sun.COM!rbbb.Eng.Sun.COM!chased
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.arch
  4. Subject: Re: Sun 600MP Benchmark Anomaly
  5. Date: 21 Jul 1992 17:25:50 GMT
  6. Organization: Sun Microsystems, Mt. View, Ca.
  7. Lines: 24
  8. Message-ID: <l6oi4uINN62e@exodus.Eng.Sun.COM>
  9. References: <5623@nosc.NOSC.MIL> <19190001@hpcss01.cup.hp.com>
  10. NNTP-Posting-Host: rbbb
  11.  
  12. In article <19190001@hpcss01.cup.hp.com> markw@hpcss01.cup.hp.com (Mark Williams) writes:
  13. >But the patch didn't really fix the anomaly.  It helped two processor
  14. >performance, but did not change the fact that 4-processor system ran no
  15. >faster than a two processor system, at least in all the benchmarks I've
  16. >seen.  
  17.  
  18. On the only benchmark that matters to me, they (running 4.1.2,
  19. probably with the patch but I really don't know) work great.  Of
  20. course, my benchmark suite is (optimizing) compiler testing.  If we
  21. had twice as many 4P 600s, I'd be twice as happy, because I'd test
  22. twice as much.
  23.  
  24. >Bottom line:  the 600MP (with SunOS 4 and the May patch) performs poorly as
  25. >an MP system, but it is a fine uniprocessor with better I/O than a workstation.
  26.  
  27. In my (limited) experience it is a fine MP system.  Careful with those
  28. blatant generalizations, sir.  I think I could make a few myself
  29. about, say, the use{ful,less}ness of pattern-matching compiler
  30. optimizations on non-SPEC codes.
  31.  
  32. Bottom line: Beware of benchmarks.
  33.  
  34. David Chase
  35. Sun
  36.