🚀 go-pugleaf

In article <C19s04.3yF@pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
>In article <1993Jan22.015827.26653@nas.nasa.gov> fineberg@nas.nasa.gov writes:
>>In article <1993Jan21.165159.10149@meiko.com>, richard@meiko.com (Richard Cownie) writes:
>>|> 
>Unfortunately, the iPSC/860 board actually takes 3 cycles for a write, so
>the count for the loop is really 7 cycles, or around 11.4 mflops
>
>The i860-XP should be somewhat better, since it can theoretically 
>issue a 128-bit load every other clock.  Of course, everything needs to
>be properly aligned, and the multiply is still 2 clocks.  So around 4-5
>clocks for a daxpy element is more likely.
>
>The problem is that peak mflops performance doesn't give the whole story --
>memory bandwidth is much more important.  Perhaps machines should be
>rated by how long it takes to do a vector add, or some such measure; then
>"super-vector" performance occurs when values can be left in vector registers.
>-- 
>Larry Meadows		The Portland Group
>lfm@pgroup.com
Actually, if there are any vendors out there, this is where peak performance 
numbers can hurt sales.  Intel misled people so much with the iPSC/860's
peak performance, that it made the Paragon look bad (i.e., it only gets 20%
better peak performance).  For the reason's you just ponted out, I expect
the Paragon to do >>20% better than the iPSC/860.  Almost all of our codes
on the iPSC/860 are memory bound. However, Intel can't advertise a >20% 
improvement in peak performancebecause they misled us before.  Of course we 
won't really know how much better the Paragon's nodes are because they have 
to contend with the extra overhead from OSF/1.

Sam