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