Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!burdvax!sdcrdcf!CAM.UNISYS.COM!mrc
From: mrc@CAM.UNISYS.COM (Ken Leonard --> ken@oahu.mcl.unisys.com@sdcjove.cam.unisys.com)
Newsgroups: comp.arch
Subject: Re: Macho flops versus Megaflops (was Re: ETA10-P performance)
Message-ID: <385@sdcjove.CAM.UNISYS.COM>
Date: Mon, 9-Nov-87 09:30:42 EST
Article-I.D.: sdcjove.385
Posted: Mon Nov  9 09:30:42 1987
Date-Received: Wed, 11-Nov-87 06:51:06 EST
References: <676@zycad.UUCP> <3322@ames.arpa>
Organization: Unisys McLean Research Center
Lines: 51
Summary: hummm -- maybe a chuckle or two -- nasty?

In article <3322@ames.arpa>, fouts@orville.nas.nasa.gov (Marty Fouts) writes:
> Kevin Buchs asks why the ETA-10 is advertised at 375 MFLOP but does 10
> MFLOP on Linpack...
> 
> ...
> 
> The bottom line is that the vendor reports the peak speed and Linpack,
> the Livermore Loops, the NAS kernels, Whetstone, et al. report how the
> vendor's compiler technology translates a particular algorithm into
> code to run the vendors architecture.  My favorite pathological case
> is a C program I wrote which runs twice as fast on a Vax as on the
> Cray 2; simply because I coded for pathological behavior on the 2.

First of all, how many folk believe that such mundane things as hardware
resource distribution/partition/allocation/proportion are at least as
important as clock speed?  If you judge by the number of systems with
per-character comm controllers ( vs. DMA ) or few-as-possible
large-as-possible disk stores ( vs. many-as-needed fast-as-possible
allocated/assigned-per-applicationstructure ), you may soon conclude
that the answer is "not very darn many."

Second, you omitted any (direct) reference to operating system architecture--
either as a matter of base family or quality of implementation/port.

UNIX is NOT a "bad system", as I am sometimes accused of saying.  Neither is
MVS not GCOS nor MS-DOS!  But ANY system can be a bad choice for a given
application, and a particular "port" of a particular system may be a
DISASTER for a particular application.

Does a number-cruncer (application) with relatively little I/O run better
on an interrupt-driven kernel, or with an interrupt-stacking kernel?  What
about a disk-cruncher?  What about a comm-cruncher?

Does a kernel with a single paging philosophy suit very many applications
very well (HECK, NO!) 

Should a compiler care that extreme "registerizing" of variables in a
high-interrupt environment means that the average context-switch time is 
doubled?  Probably, it should (be able to be told to) care VERY much.

Should a compiler care that bank-interleaved allocation of the biggest array
may not be as important as being told which array actually is subject to
the majority of vector operations?

Gee, what ever happened to the idea of considering the whole problem
before leaping to a solution?

regardz to all,
Ken Leonard

!--> ken@oahu.mcl.unisys.com@sdcjove.cam.unisys.com