🚀 go-pugleaf

In article <8699@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
...
>  But than we get at the standard question: what should
>you use?

I rather like using Dongarra's Linpack report (either the Best Effort
with n=1000, or for some systems, the Rmax from Table 3 with n selected
by the vendor.  These benchmarks measure actual solution of real problem,
under almost ideal conditions.  They also are widely available and regularly
updated.  Jack makes serious efforts to keep the vendors honest.  There are
very few application/machine combinations which will show higher Gflop
ratings than that provided by these numbers, so that benchmark can be
considered the realistic attainable peak for 64-bit floating point
operations.  Be careful when quoting a higher 32-bit peak to note the 64-bit
performance also.

Of course, any careful evaluation of super architecture needs to take
into account peak achievable megaflops (Linpack), memory bandwidth
(McCalpin's Stream), sustainable I/O bandwidth (to disk and high speed
network) as a proportion of peak megaflops, and ease of achieving
significant fractions of these peaks on real application codes.

We have already discussed Gflops and memory megabytes/sec.
Any opinions on the amount of I/O bandwidth necessary to support/sustain
a useful Gflop in a production environment?  My intuition is that 10
Mbytes/second is a bit skimpy, while 100 Mbytes/second is ample.  Is that
the right range?  Anyone have actual application performance requirements?

By the way, I mean actual, delivered data to an application, not peak
hardware specs of the fastest bus on the system.  Specmanship is really
common in quoting I/O performance, just as peak Mflops is common.  Alertness
on the part of you users, writers, and reviewers is necessary to keep us
vendors from playing spiraling artifical, meaningless number games.