Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcsvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!tektronix!hplabs!sdcrdcf!sdcsvax!jww
From: jww@sdcsvax.UUCP (Joel West)
Newsgroups: net.arch
Subject: Re: Scientific Computing and mips
Message-ID: <1062@sdcsvax.UUCP>
Date: Tue, 27-Aug-85 16:41:26 EDT
Article-I.D.: sdcsvax.1062
Posted: Tue Aug 27 16:41:26 1985
Date-Received: Mon, 2-Sep-85 03:28:32 EDT
References: <419@kontron.UUCP> <2300001@uicsl> <1093@ames.UUCP> <29898@lanl.ARPA> <1517@peora.UUCP> <30105@lanl.ARPA>
Organization: CACI, Inc - Federal, La Jolla
Lines: 52

> > > It helps draw the line between special purpose and general purpose
> > > environments (or, less tactfully, usable and unusable machines)..
> >
> > .... what properties of general purpose
> > environments make them "unusable" for scientific/engineering computing?

Another side issue that certain problems benchmark certain ways.
For example, in supporting a SIMSCRIPT II.5 discrete-event simulation,
we find that the best predictor of user performance is double-precision
("single" on your Cray, george) floating point speed.  There are a
lot of floating point comparisons on the event chain, plus the heavy
use of psuedo-random gamma functions, etc. requires F.P. multiplies and
divides.

For compilation, however, integer performance -- particularly simple moves
and single-level indirect addressing -- is the best predictor of speed.
I suspect this would also be true for typical throughput on development 
machines  (vs. scientific number crunchers).  That's why machines with 
strong integer scalar performance (e.g., Cray 1?) have it over those that 
focus only on MFLOP's.

> MIPS measurements provide a microscopic view of machine performance that is
> open to interpretation and is less desirable than benchmarks that are
> far too large to permit hand optimization and tuning.

When benchmarking two dissimilar anythings--software, hardware, etc.--I
consider most benchmarks accurate only within a factor of 2, if that.
Benchmarks typically are several hundred lines, with limited complexity
and usually small data cases.  If you want to test typical throughput,
you need a typical program--even if that means manipulating 200,000
lines of source.  This also assures that if the system was "tuned",
it was probably a very limited sort of tuning that any owner of such
program would try anyway.

> It's my belief that this market requires
> "general purpose architectures" with "general purpose (usable) environments"
> (or else you have no hope of even compiling and loading the code, where the
> full load map can exceed 50,000 lines alone).  
> 	george spix       gas@lanl

There have been no shortages of proposed architectures.  There
haven't been as many "usable architectures," in the sense that
they will take the 200,000 line program off the shelf and run it.

A clever user will take "Program A" and put it up on machines X,Y,Z,
spending less than a week on each test.  Which ever machine runs it
fastest, wins.  From the user's standpoint, that's much better
than listening to MIP's, MFLOP's, or other mumbo-jumbo.

	Joel West	CACI, Inc. - Federal (c/o UC San Diego)
	{ucbvax,decvax,ihnp4}!sdcsvax!jww
	jww@SDCSVAX.ARPA