Xref: utzoo comp.lang.c:11362 comp.arch:5529 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Summary: sometimes you win and... Message-ID: <478@proxftl.UUCP> Date: 16 Jul 88 13:44:51 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <60175@sun.uucp> Organization: Proximity Technology, Ft. Lauderdale Lines: 15 In article <60175@sun.uucp>, petolino%joe@Sun.COM (Joe Petolino) writes: > >> 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... > ...Take this with a grain of NaCl: we only > tried a few test programs, and each was small enough to fit into the cache. Another relevant point about separate caches is this: instructions and data have different access patterns. A cache designed for the one is not necessarily going to be right for the other; a cache designed for both may not do as well as the separate ones. So this possibility has to be balanced against the general benefit of having a larger pool to work with.