Benchmarking (was Re: Is this a reasonable platform for SCO Unix?)

[Wes Peters]

In article <309 at raysnec.UUCP>, shwake at raysnec.UUCP (Ray Shwake) writes:
> 	Great. You've shown that a 486/25 can run Dhrystones and short loops
> under elk as well as a SparcStation 1+. Is *that* what you do all day? Has it
> occurred to you that these tests, and others of their ilk, provide only the
> crudest indication of relative performance? Well, consider it. How tragic
> that, as hardware, operating environments and applications have become more
> sophisticated, people still give credence to such quick-and-dirty
> measurements.

When I was in college, we developed a simple benchmark for microcomputers
that still holds true for workstations today, for the software development
work that I do:

1- kermit the source code for Dave Betz' public-domain Lisp interpreter to
   the machine (if it can't run kermit, something is seriously wrong with
   it :-)

2- make the lisp executable, note the time.  This is benchmark time #1.

3- run the lisp program.  Type in a simple routine to calculate factorials
   using tail recursion.  Calculate 69!, note the time.  This is benchmark
   time #2.

This isn't the be-all, end-all of benchmarks, but it does give you some idea
of how fast the system can compile and link, and some idea of the integer
performance.  For software development, the only other test I can think of
is 'Does it have a good editor?'  Replace 'good editor' with the name of
your favorite.

Of course, the best benchmark is to spend a week or two doing what you
normally do with the machine under test.  This will give you a REAL good
idea how well the machine will perform ASAP.

	Wes Peters
-- 
#include <std/disclaimer.h>                               The worst day sailing
My opinions, your screen.                                   is much better than
Raxco had nothing to do with this!                        the best day at work.
     Wes Peters:  wes at harem.clydeunix.com   ...!sun!unislc!harem!wes