🚀 go-pugleaf

First we read that:

|> The cache will affect all OS's.  By way of example, a 486 with 32MB RAM
|> was incorrectly configured to cache only the first 16MB.  We saw
|> benchmark deterioration on the order of 2 depending on whether the
|> application was using the cached or uncached RAM.  (this was under OS/2
|> 2.11).  That is, when the OS happened to load the application into the
|> cached RAM it ran almost twice as fast as when loaded into the uncached
|> RAM.  These randomly varying results of our benchmark were very
|> puzzling until we figured out what was really going on.  In any case,
|> the conclusion is clear, the cache is very important.
|> 
|> 
|> -- 
|> Jon Hacker                         |   OS/2 2.1
|> Bellcore, Red Bank NJ              |   accept no substitutes 
|> hacker@patagonia.bellcore.com      |   

Then we also read that

|> 	The most compute-intensive task I could find, a SPICE simulation 
|> running on a RAMdrive (minimal video usage, no hard disk access after 
|> start of simulation) runs 20% faster with 256K cache installed on my 
|> 486DX-33 (Gosling motherboard).  For most "ordinary" tasks, the difference 
|> is well under ten percent (that is, unnoticeable unless you get out your 
|> stopwatch).  For faster processors the difference would presumable be 
|> greater.
|> 
|> -----
|> Greg Thoman:  The opinions expressed herein are mine alone, and I am 
|>               solely irresponsible for them.


So what's the scoop!?

Well, actually the effect of the L2 cache is MUCH more pronounced in a DX2
then a DX. An intuitive reason is that a cache miss in a DX2 will stall
twice as many CPU cycles and hence takes a much greater performance penality.

On my DX2-66 running Linux, I get about 70% speed increase from enabling the
L2 cache write through cache, and then another 10% increase from switching to
using write back cache (both 256K direct mapped.) 

On the other hand, my brother who has a DX-33 also with 256K L2 cache told me 
that his observed increase is only about 18-20%. 

In both cases, the improvement estimates were real time estimates obtained from
compiling the Linux kernel using gcc, so they include both ram and disk access
overheads as well. 

Obviously different configurations (ram size, disk speed, bus speed etc) will
exhibit different speed up factors. The data points here though, hopefully
would represent typical ball park figures for those who are interested....

-- John