Subject: Second level cache?

From: Bill Broadley <[email-masked]>
Date: Mon, 9 Aug 1993 10:52:43 -0500 (EDT)

Somebody mentioned that some research needs to be done on how a second level 
cache will effect performance.  Any suggestions on how to do this?

Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
internal) clock rate, and mips binaries being bigger then 486 it would
seem that a large secondary cache would be necessary.  Based on a 486's
secondary cache being useful.

Any suggestions on how to get some numbers experimentally?

I have a decstation 3100 running Ultrix, and a 486/66 running linux
available for any attempts to quantify the advantages of second level
cache's.

--
Bill					1st>	[email-masked]
[email-masked] <2nd 	3rd> 	             [email-masked]
Linux is great.         Bike to live, live to bike.                      PGP-ok

---

From: [email-masked] (Bill Henning)
Date: Mon, 9 Aug 1993 21:11:23 -0700 (PDT)

> cache will effect performance.  Any suggestions on how to do this?

One data point: 486DX2/66, IBM's CSet/2 compiler, 16Mb ram, 256k L2 cache
compile time is aprox. 2.5x faster with the L2 cache than without.

> around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Agreed.

> secondary cache being useful.

I would suggest 256k expandable to 1Mb. Maybe someone could run some apps
on the MIPS simulator, and instrument the emulator to record the saved cycles
for caches of different sizes.

> Any suggestions on how to get some numbers experimentally?

See above.

> available for any attempts to quantify the advantages of second level

Can you turn its L2 cache off under software/hardware control?
If you can, you might want to try the following with the L2 cache enabled/
disabled, and if you do, please post both sets of numbers:

- recompiling gcc
- cross compiling the Linux kernal
- x11perf
- a database test of some sort
- the Byte unix benchmarks

Bill