From: eric@snark.thyrsus.com (Eric S. Raymond)
Newsgroups: comp.benchmarks
Subject: Tooling up for the Great 1992 UNIX Dream Machines Bake-Off
Date: 9 Apr 92 14:17:19 GMT
Distribution: world

In preparation for the Great 1992 UNIX Dream Machines Bake-Off, I snarfed the
entire comp.benchmarks archive from wustl and read it all.  I'm under no
delusions that this makes me an expert, but at least my ignorance has been
somewhat lessened. :-)

My current plan for the Bake-Off is to collect, for each machine, the
following benchmarks:

	* SPEC 2.0 results, concentrating on SPECint and SDM numbers.

	* The bonnie number (with due caveats about caching effects).

	* The iozone report.

	* Aburto's FLOPS approximation.

Is anyone maintaining bonnie and iozone numbers lists?  They'd be useful for
putting the Bake-Off results in context.  Not being one o' them "scientific
computing" weenies with a floating-point fixation :-), I rank disk throughput
about second on the list of useful predictive measures, just after integer-
and logical-operation speed.

I don't plan to bother with Dhrystone unless someone persuades me that it's
of sufficient historical interest.

Just for giggles, I may add BCmark and that DPS thing (I'm amazed nobody has
advanced the obviously correct name for it --- Datestones!).

I plan, also, to include TeX's elapsed-time-to-crunch on a big document;
all 433 pages of the Jargon File master, as a matter of fact.

Does this sound like a reasonable plan, oh boffins assembled?  Bearing in mind
that the machines are likely all going to be 486-DX/50s, with the biggest
variable ISA vs. EISA bus, that is --- thus, the performance variations should
be conditioned primarily by the cache hit rate, disk seek time and disk
transfer rate.

So I'm sitting here playing with the various synthetic benchmarks I'm planning
to use, and of course I run them on my soon-to-be-replaced tired AT&T iron,
which has the dubious merit of combining absolutely stock AT&T 3.2 UNIX with 
an unusual speed (20MHz --- try finding one of *those* any more).

Here's an iozone auto report for my system (AT&T 6386WGS with ESDI controller
and a Micropolis 300MB drive).  

	MB      reclen  bytes/sec written   bytes/sec read      
	1       512     75983               42298               
	1       1024    74419               43455               
	1       2048    78545               45041               
	1       4096    78427               44964               
	1       8192    79739               43311               
	2       512     75491               49079               
	2       1024    76510               50741               
	2       2048    72215               51501               
	2       4096    76510               52785               
	2       8192    73895               47814               
	4       512     81080               62817               
	4       1024    86178               73109               
	4       2048    85843               67847               
	4       4096    86054               72944               
	4       8192    86712               72843               
	8       512     81992               62294               
	8       1024    83860               70575               
	8       2048    83793               67770               
	8       4096    85258               69115               
	8       8192    84562               70528               
Error writing block 29420

I ran out of space at that point.  Now, what puzzles me is the consistant
disparity between the read and write numbers.  Anyone have a theory on this?

Here's an appropriate change to <2005@marlin.NOSC.MIL>, Alfred Aburto's
flops.c results table.

*** old-results	Wed Apr  8 22:35:34 1992
--- new-results Wed Apr  8 22:48:20 1992
***************
*** 129,134 ****
--- 129,136 ----
  AT 386           SCO UNIX, cc -O  (MS)     80386/80387  25.0   0.3989   15
  AT 386           SCO UNIX, rcc -O (AT&T)   80386/80387  25.0   0.3927   15
  AT 386           SCO UNIX, gcc -O (1.40)   80386/80387  25.0   0.3070   15
+ AT&T 6386WGS     AT&T V.3.2, cc -O -DROPT  80386/80387  20.0   0.2311   26
+ AT&T 6386WGS     AT&T V.3.2, cc -O         80386/80387  20.0   0.2290   26
  VAXstation 2000  Ultrix 4.2, cc -O         -----------  ----   0.1520   11
  Amiga 2000/MMR   Aztec C 3.6a/68882 m.lib  68030/68882  33.3   0.0703   12
  Siemans MX2      SINIX Versn 2, cc -lm -O  -----------  ----   0.0516   19
***************
*** 160,165 ****
--- 162,168 ----
  23  Meinhard E. Mayer, UC Irvine, CA, USA, hardy@golem.ps.uci.edu
  24  Todd McDaniel, scooter@emunix.emich.edu
  25  Steve Kelsey, CSA, San Diego, CA, USA, 'skelsey' on BIX. 
+ 26  Eric S. Raymond, Eric Conspiracy Secret Labs, USA, eric@snark.thyrsus.com
  
  Al Aburto
  aburto@marlin.nosc.mil

And here's a port patch for iozone 1.14b.  Bill Norcott, got yer ears on?

*** iozone.c~	Thu Apr  9 00:15:07 1992
--- iozone.c	Thu Apr  9 00:29:19 1992
***************
*** 74,79 ****
--- 74,80 ----
    " ",
    "    Vendor             Operating System    Notes on compiling IOzone",
    "    -------------------------------------------------------------------------",
+   "    AT&T 6386WGS       AT&T UNIX 5.3.2     define SYSTYPE_SYSV"
    "    Convergent         Unisys/AT&T Sys5r3  cc -DCONVERGENT -o iozone iozone.c",
    "    Digital Equipment  ULTRIX V4.1 ",
    "    Digital Equipment  VAX/VMS V5.4        see below **         ",

I'm too short of disk to run bonnie.
-- 
      Eric S. Raymond = eric@snark.thyrsus.com  (mad mastermind of TMN-Netnews)
Newsgroups: comp.benchmarks