Xref: utzoo comp.lang.c:11350 comp.arch:5521
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!joe!petolino
From: petolino%joe@Sun.COM (Joe Petolino)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Message-ID: <60175@sun.uucp>
Date: 15 Jul 88 23:23:13 GMT
References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <33518@yale-celray.yale.UUCP> <1087@ficc.UUCP> <14017@apple.Apple.COM>
Sender: news@sun.uucp
Reply-To: petolino@sun.UUCP (Joe Petolino)
Organization: Sun Microsystems, Mountain View
Lines: 16

>>	Why are an Icache plus a Dcache better than just
>>	a big shared cache as big as both?
>
>In terms of hit/miss ratios, a unified cache is clearly better.

I beg to differ.  We ran a few simulations, comparing split and unified
caches (total cache size in the 32K-512K range), and when the caches were
direct-mapped (i.e. 1-way set-associative) the unified cache performed worse. 
Our guess is that when code and data are forced to co-exist in the same
space, you get a high probability of collision and thrashing.  This effect
went away when we increased the degree of set associativity.  One way to
think about it is that having two (direct-mapped) caches gives you some of
the benefits of set-associativity.  Take this with a grain of NaCl: we only
tried a few test programs, and each was small enough to fit into the cache.

-Joe