home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / super / 1195 < prev    next >
Encoding:
Text File  |  1993-01-24  |  2.2 KB  |  43 lines
  1. Newsgroups: comp.sys.super
  2. Path: sparky!uunet!stanford.edu!ames!data.nas.nasa.gov!wilbur.nas.nasa.gov!fineberg
  3. From: fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg)
  4. Subject: Re: i860 performance (was: Re: World's Most Powerful Computing Sites)
  5. References: <1993Jan21.165159.10149@meiko.com> <1993Jan22.015827.26653@nas.nasa.gov> <C19s04.3yF@pgroup.com>
  6. Sender: news@nas.nasa.gov (News Administrator)
  7. Organization: NAS, NASA Ames Research Center, Moffett Field, CA
  8. Date: Sat, 23 Jan 93 20:58:53 GMT
  9. Message-ID: <1993Jan23.205853.22421@nas.nasa.gov>
  10. Lines: 31
  11.  
  12. In article <C19s04.3yF@pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
  13. >In article <1993Jan22.015827.26653@nas.nasa.gov> fineberg@nas.nasa.gov writes:
  14. >>In article <1993Jan21.165159.10149@meiko.com>, richard@meiko.com (Richard Cownie) writes:
  15. >>|> 
  16. >Unfortunately, the iPSC/860 board actually takes 3 cycles for a write, so
  17. >the count for the loop is really 7 cycles, or around 11.4 mflops
  18. >
  19. >The i860-XP should be somewhat better, since it can theoretically 
  20. >issue a 128-bit load every other clock.  Of course, everything needs to
  21. >be properly aligned, and the multiply is still 2 clocks.  So around 4-5
  22. >clocks for a daxpy element is more likely.
  23. >
  24. >The problem is that peak mflops performance doesn't give the whole story --
  25. >memory bandwidth is much more important.  Perhaps machines should be
  26. >rated by how long it takes to do a vector add, or some such measure; then
  27. >"super-vector" performance occurs when values can be left in vector registers.
  28. >-- 
  29. >Larry Meadows        The Portland Group
  30. >lfm@pgroup.com
  31. Actually, if there are any vendors out there, this is where peak performance 
  32. numbers can hurt sales.  Intel misled people so much with the iPSC/860's
  33. peak performance, that it made the Paragon look bad (i.e., it only gets 20%
  34. better peak performance).  For the reason's you just ponted out, I expect
  35. the Paragon to do >>20% better than the iPSC/860.  Almost all of our codes
  36. on the iPSC/860 are memory bound. However, Intel can't advertise a >20% 
  37. improvement in peak performancebecause they misled us before.  Of course we 
  38. won't really know how much better the Paragon's nodes are because they have 
  39. to contend with the extra overhead from OSF/1.
  40.  
  41. Sam
  42.  
  43.