home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / super / 1186 < prev    next >
Encoding:
Text File  |  1993-01-21  |  2.9 KB  |  62 lines
  1. Newsgroups: comp.sys.super
  2. Path: sparky!uunet!stanford.edu!eos!data.nas.nasa.gov!wilbur.nas.nasa.gov!fineberg
  3. From: fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg)
  4. Subject: Re: World's Most Powerful Computing Sites
  5. References: <1993Jan20.232809.29241@nas.nasa.gov> <1993Jan21.165159.10149@meiko.com>
  6. Sender: news@nas.nasa.gov (News Administrator)
  7. Organization: CSC, NASA Ames Research Center, NAS Division
  8. Date: Fri, 22 Jan 93 01:58:27 GMT
  9. Message-ID: <1993Jan22.015827.26653@nas.nasa.gov>
  10. Reply-To: fineberg@nas.nasa.gov
  11. Lines: 49
  12.  
  13. In article <1993Jan21.165159.10149@meiko.com>, richard@meiko.com (Richard Cownie) writes:
  14. |> fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg) writes:
  15. |> : In article <1993Jan20.211032.11929@hubcap.clemson.edu>, richard@meiko.com (Richard Cownie) writes:
  16. |> : |> This seems to imply a figure of over 4MFLOPS per T800.  Last time
  17. |> : |> I programmed one, it was a real struggle to achieve over 1MFLOPS
  18. |> : |> even for inner loops of vector routines.  Not that 4MFLOPS is
  19. |> : |> necessarily a lie, you might manage it if you're adding two 32-bit
  20. |> : |> zeros (and never storing the result).  But it's certainly stretching
  21. |> : |> the truth a long way: there are lies, damned lies, and statistics.
  22. |> : |> 
  23. |> : |> -- 
  24. |> : |> Richard Cownie (a.k.a. Tich), Meiko Scientific Corp 
  25. |> : |> email: richard@meiko.com
  26. |> : |> phone: 617-890-7676
  27. |> : |> fax:   617-890-5042       
  28. |> : |> 
  29. |> : Its certainly no less realistic than those for the i860.
  30. |> : 
  31. |> : Sam
  32. |> 
  33. |> I have to disagree with you there.  I know of *some* applications where
  34. |> the i860 can achieve a good fraction of claimed peak speed, e.g. on
  35. |> a double-precision matrix multiply you can do over 35MFLOPS, against
  36. |> a peak rate claimed as 40MFLOPS (or sometimes 60MFLOPS, because you can do
  37. |> 2 adds for each multiply).  In any case, it's well over 50% of peak.
  38. |> 
  39. |> If a T800 transputer can achieve 50% of 4.4MFLOPS on a matrix multiply,
  40. |> or indeed *anything* useful, I'd be interested to hear about it.
  41. |> 
  42. |> Performance on big compiled Fortran programs is another kettle of fish,
  43. |> and here I'd agree that peak performance figures are not much help.
  44. |> -- 
  45. |> Richard Cownie (a.k.a. Tich), Meiko Scientific Corp 
  46. |> email: richard@meiko.com
  47. |> phone: 617-890-7676
  48. |> fax:   617-890-5042       
  49.  
  50. I don't know too many people that write assembly code, and that is what you
  51. need to do to get 35 MFLOPs.  As far as I'm concerned, assembly coded
  52. benchnmarks are useless.  And if you can't get more than 60% of peak on an
  53. assembly coded matrix multiply, that is bad (when Intel quotes peak speeds
  54. on its system it uses the 60MFLOPs number, or 75 for the Paragon). The best I
  55. have ever seen on an i860 was 10-15Mflops, and that was because the compiler
  56. had stuck in some special vector subroutines in my code where it recognized
  57. a daxpy operation.  I don't know what the transputer is capable of, but I would
  58. be surprised if it can't do 75-90% of peak for a useless assembly coded 
  59. benchmark.
  60.  
  61. Sam
  62.