David Kanter (dkanter@realworldtech.com) on 9/7/09 wrote:
---------------------------
>>>I$ & D$'s have different associativity needs. For instance, Nehalem and POWER6 have 4-way I$ and 8-way D$.
>>
>>Yes all good points, thanks. And I agree, I just wonder if you took out all the
>>(many) physical implementation disadvantages of a shared L1 cache and purely simulated
>>the effect of data evicting instructions from a unified cache versus 2 smaller split
>>caches, then what kinds of advantages / disadvantages would you see.
>>
>>I mean, with a perfect "oracle" cache, surely a larger unified one will always
>>be better than any number of perfect split smaller ones. It simply could put more
>>of the cache towards adapting to the workload.
>
>Sure, but an oracle cache isn't realistic, and it also doesn't have unlimited R/W ports.
>
>>But on the other hand, of course instruction fetch versus data operations is a
>>strong input as to what the access pattern will be. That is not to say that input
>>has to be ignored in a unified cache, but implementation-wise it is probably hard
>>to do (but, seeing as we're already ignoring difficult >implemntation details, let's ignore this too :)).
>
>Ignoring implementation details isn't a good idea since computer architecture is deeply tied to those details.

Yes it is. Because we have already established that for vast majority of systems that unified cache is much harder for implementation details. I just want to ignore those to see if there are any real upsides to unified L1 caches (even if completely theoretical and unachievable in practice eg. due to inherently slower unified cache).

>>I'm just really interested in the statement that unified I/D caches is unsuitable
>>for LRB type application (statement was made in a way that it sounded like it was
>>opposed to some other applications where unified I/D would >be a good idea).
>
>A machine that heavily relied on self-modified code would probably want to have
>the I$ look more like a D$ (full coherency).

Hmm, possibly. That still doesn't automatically give you coherency because you'll have an instruction fetch queue and cpu pipeline that needs to be kept coherent...

So with x86 model which requires coherent instruction cache with SMC, doesn't the core have to be probing/tracking the icache some way or the other on each data store *anyway* (even in the case of non-smc)? They seem to do quite well with split caches.