Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!midway!quads.uchicago.edu!rtp1
From: rtp1@quads.uchicago.edu (raymond thomas pierrehumbert)
Newsgroups: comp.sys.hp
Subject: Re: A benchmark
Message-ID: <1991May9.155313.8671@midway.uchicago.edu>
Date: 9 May 91 15:53:13 GMT
References: <1991May3.023705.5616@marlin.jcu.edu.au> <5570629@hpfcdc.HP.COM>
Sender: news@midway.uchicago.edu (NewsMistress)
Organization: University of Chicago
Lines: 42

Chuck Cairnes of HP writes:
<like to see the actual numbers on the higher speed IBM's. I kinda suspect
<that they wouldn't scale well with clock speed. Hmmm  What't the cache to
<main-ram width on the IBM's.

I have done extensive benchmarks on both the IBM model 530 and model 550.
These are a broad range of large 2D fluids codes and misc. chaos
codes.  Also FFT's and matrix multiplies.  In all cases, the speedup
went with the clock-ratio.  This is expected, as the 550 uses
faster memory and a faster bus. The more extensive testing of the
Los Alamos group (with a 540) supports this result.

In going from a 520 to a 550, the speed up is a lot MORE than the
clock ratio, because the 550 has a larger cache. I think probably
the superior numerical performance of the IBM architecture is
due to the superscalar processor, but it also may have something
to do with the bandwidth between memory and cache, since we're
talking about out-of cache codes here for both machines.  The
IBM has 128byte cache lines.  If you have a cache miss, it
takes 8 cycles to load the needed line.  Thus, in a streaming
mode, the bandwidth to cache is 16 bytes/cycle (or 672MB/sec on
a 550).  Given that the cache is 4-way set associative rather
than direct mapped, there can also be degradation due to certain
special memory access patterns.  Misses in the TLB take more
cycles to fix, but are rather rare.

I doubt that cache thrashing is a big problem with the ocean
model code. It was written very carefully for a Cyber 205
originally, and the Cyber really choked on non-unit strides. I
haven't seen the code in a while, though.  It is not
especially optimized for re-use of data, given the Cyber/Cray
architecture, but this is an equal performance hit on the
IBM and HP architectures.

So, we have a problem here.  How do we reconcile HP's published
float performance figures with the results on this real
scientific model code?  Do we perhaps have a compiler that
can do Linpak and specfp efficiently but nothing else?  That
certainly was the case on my DN10k, for example, where the
10.6 fortran compiler clearly had some kludges in it that
had the sole effect of making compiled BLAS run faster (and
just about nothing else).