🚀 go-pugleaf

In article <danpop.809044652@rscernix>, Dan Pop <Dan.Pop@mail.cern.ch> wrote:
>
>Hardware design texts aren't the "industry".  It is very easy to point
>out the problems of a certain solution.  It's considerably more difficult
>to come with a better solution.  Until now, nobody came with a better
>solution than the SPEC benchmarks to the problem of evaluating the
>relative performances of computers as general purpose systems.  If you
>don't hear very often of the SPEC data for a Cray, it is because a Cray
>is not a general purpose system.  Most Unix workstations and servers are.
>
>If you have a better solution for this problem, please don't keep it for
>yourself :-)

  Not my conversation, but I've got a suggestion..

  Anyone who's taken high school calculus could sit in on an Algorithms
Analysis class (CIS101 at UCSC, where I took it -- the upper-division
computer science course was a pre-req for any other CIS course).  Then
you can thumb through the reference text for the system you're interested
in, look at the algorithms used by the application in question, click a
few keys on your calculator, and know to a very precise degree what kind
of performance you can expect out of that application on that system.

  It's more reliable and more meaningful than SPEC, and it's what I've
been doing for years.  For CPU-intensive algorithms you mostly have to
pay attention to CPU and memory architecture.  For disk-intensive algor-
ithms you mostly have to pay attention to disk and OS architecture.  In
any case you can quickly establish the most interesting cases of that
algorithm's operation and determine how quickly it will run in those
cases.  Most of the time you don't even need to look at the source code;
a familiarity with what the system is doing will be enough.

  Microsoft users:  You're doomed.


-- 
Bill Moyer <ttk@rahul.net>