home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8485 < prev    next >
Encoding:
Internet Message Format  |  1992-07-31  |  3.1 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!cronkite.Central.Sun.COM!sixgun.East.Sun.COM!chessie!pmorris
  2. From: pmorris@chessie.East.Sun.COM (Phillip Morris - SE Washington D.C.)
  3. Newsgroups: comp.arch
  4. Subject: Re: Call for Opinion: Viking or i860
  5. Date: 31 Jul 1992 11:57:38 GMT
  6. Organization: Sun Microsystems, Inc.
  7. Lines: 58
  8. Distribution: world
  9. Message-ID: <15b9riINN3o4@sixgun.East.Sun.COM>
  10. References: <5678@nosc.NOSC.MIL>
  11. Reply-To: pmorris@chessie.East.Sun.COM
  12. NNTP-Posting-Host: chessie.east.sun.com
  13.  
  14. In article 5678@nosc.NOSC.MIL, wolfgang@sunspot.nosc.mil (Lewis E. Wolfgang) writes:
  15. >Call for opinion:
  16. >
  17. >    We run large acoustic modeling programs on a
  18. >variety of Sun Sparc systems and in the past have
  19. >considered purchasing array processors to hasten things
  20. >along.  It seems as if many array processors are based
  21. >on Intel's i660 chip, certainly a respectable 
  22. >numerical masticator, but how does it stack up against
  23. >current RISC based CPUs?
  24. >
  25. >    We have a Sun 690MP that we could upgrade to
  26. >SuperSparc (Viking) with SuperCache for not much more
  27. >money than an equal number of i860 based processors.  
  28. >It seems as if integer performance is better with Sparc,
  29. >with floating point not quite as good.  An advantage of
  30. >a Sparc upgrade is that old code would not have to be
  31. >modified, at a cost of slightly less relative floating 
  32. >point performance.
  33. >
  34. >    What do you think?  Upgrade the cpu with Viking?
  35. >Or purchase an equal number of i860 based array processors?
  36. >
  37. >                Thanks,
  38. >                Lew Wolfgang
  39. >                wolfgang@nosc.mil
  40. >
  41.  
  42.  
  43. Mr. Wolfgang,
  44.  
  45. After noting that I work for Sun, please also be aware that this is a new position (only been here
  46. 3 months) and that my previous jobs were at ATT Bell Labs & BBN, both positions as a near-real-time
  47. programmer on Sun SparcStations.  Most of the stuff we did was digital signal processing which is
  48. quite floating point intensive.  For a long while we used either TI or ATT DSP chips, but when our
  49. computing needs got more general than just the dsp code, we needed a more general floating point
  50. processor.  We tried out both the Sky & Mercury i860 boards (4 processors) and found that the only
  51. way to get anywhere near the stated MFLOPS rating was by hand coding in assembly.  The C 
  52. cross-compilers stank!! Any 1st year CS student could have optimized better for a particular cpu
  53. than those compilers did.
  54.  
  55. All this is to say this:  Don't pay any attention *AT ALL* to stated performance figures.  Either
  56. get a loaner piece of equipment and try out your code, or package the demanding part of your code
  57. into a easily compilable/runnable package and send it to the various manufacturers to let them
  58. perform benchmarking (and make SURE to get exactly how they compiled and ran it).  Then you have a
  59. basis for fair comparison.
  60.  
  61. My guess, based upon previous experience, is that unless you plan to hand code assembly for the i860,
  62. then you will get *better* FP performance out of the SuperSparc (Viking) with the new SparcCompiler
  63. that has been optimized for that architecture.
  64.  
  65.  
  66. ---
  67. ------------------------------------------------------------------------------
  68. -Phil Morris, SE w/ Sun Microsystems in Vienna, VA
  69. -pmorris@chessie.East.Sun.COM
  70.  
  71.  
  72.