gas@lanl.ARPA (08/25/85)
> > It helps draw the line between special purpose and general purpose > > environments (or, less tactfully, usable and unusable machines).. > > I assume you mean "special purpose" environments are "usable" whereas > "general purpose" ones are "unusable"... what properties of general purpose > environments make them "unusable" for scientific/engineering computing? Sorry the statement was not crystal clear - the observation is that 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. Artistic issues aside, what will determine success is market share, and the way to gain market share and credibility in the scientific/engineering market is with this type of benchmark (MSC/Nastran). 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). I don't think a special purpose architecture (e.g. an ap) can provide an "easily used" environment, and is therefore at a severe disadvantage in the market. My caution to architects is not to be myopic when approaching performance measurement. Respected benchmarks do exist for the engineering and scientific marketplace. These codes determine raw machine performance and the likelyhood that the typical user will see that benefit. george spix gas@lanl (if the factorial of 0 is 1, is uncertainty certain?)
jww@sdcsvax.UUCP (Joel West) (08/27/85)
> > > 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
bob@islenet.UUCP (Bob Cunningham) (08/31/85)
> ... > I don't think a special purpose architecture (e.g. an ap) can > provide an "easily used" environment, and is therefore at a severe > disadvantage in the market... Which, however, doesn't negate the usefullness of such devices as specialized co-processors attached to a more general machine. There are a variety of different types of scientific computation that require basically similar mathematical manipulations, e.g. FFTs, convolution, matrix & vector calculation, etc. Typical programming practice uses subroutines for these, and there's no reason not to "plug in" similar calls to an ap in a reasonably transparent fashion, and take advantage of being able to do those calculations on a specialized coprocessor. -- Bob Cunningham {dual|vortex|ihnp4}!islenet!bob Hawaii Institute of Geophysics
gas@lanl.ARPA (09/03/85)
Another area worth some study (in terms of "usable" architectures) is
"balance". Any rough guesses (order of magnitude) on what the memory and
io bandwidth of a Cray X-MP 48 is? An IBM 3081K?, A Vax 8600?,
A VP200?, An FPS 164?, A Cyber 205?, A Hep?, A Hypercube?. Perhaps
mips are a measure of intelligence and machine bandwidth a measure of
muscle - here again, large, untunable benchmarks (e.g. MSC/Nastran) are
hard to top when it comes to comparing architectures.
george spix gas@lanl
(a teaser - which of the above can support io traffic in excess of 20gbit/s
and maintain rated cpu speeds?)