[rescue] Re: Re: OH YEA??? [was: Re: Ultra?]

[Dave McGuire]

On August 5, Koyote wrote:
> >   And I suppose next you're going to tell us that ALL Ultra5s come in
> > this configuration.  Ultra5s with useful cache are by far the least
> > common and most expensive.  To follow your logic, I could say
> > something like "since there are SPARCstation-10 systems with 150MHz
> > processors, ALL SPARCstation-10 systems have 150MHz processors!"
> 
> Okay- correct me if I'm wrong- because I seem to find the "feel" of various workstations to point to a u10/300 being overall a bit snappier than a dual sm81-1 384meg ZX ss20. (yeah, this is a u10 with scsi)
> 
> While I see the joys of cache for some types of work, do you need 1meg of cache for 256k of work? does the chache gain you the difference between (depending on the comparison)  32bit at 40mhhz vs 64bit at 270  or, alternatively (and more realistically, IMO) 2x32bit at 85mhz and 64bit at 300mhz?
> 
> I'm not knocking cache, and I've got some really nice, stable, long haul performance out of ss20 servers. I'm just curious if that much external cache makes that much difference-

  It depends *entirely* on the kind of code running on the processor.
A cache will rarely negatively impact performance in any real way, but
if the code in question is "cache friendly" a larger cache can be a
big win.  It's certainly reasonable that, for a given OS and
application software mix, that you might not see any benefit from a
larger cache.  There are other attributes of cache design that come
into play...cache type (write through, write back, etc), line size,
etc...that can also have a dramatic effect on performance given
certain memory access patterns.

  Just as a side note, in my experience the worst cache-friendliness
offenders have been arrays whose sizes are even numbers, or even
worse, powers of two.  This is a very common programming practice that
blows most caches out of the water.  Many programmers "think" in terms
of powers of two, so instead of a 100-element array they'd make it 128
elements, when it should probably be something like 97 or 101.
Another big one is highly randomized array access.

  Anyway...There's no such thing as a "magic" cache size or type that
works best for all types of code, though some tend to work a bit
better than others in general applications.  For a very thorough and
interesting treatment of this topic, I refer you to "High Performance
Computing" by Dowd & Severance.

          -Dave

-- 
Dave McGuire                     "I haven't worn pants in 14 months!"
St. Petersburg, FL                                   -Pete Wargo