David Kanter (dkanter@realworldtech.com) on 4/20/12 wrote:
---------------------------
>
>You are correct that the caches are painfully slow, but that's not the reason why.
>Frankly, I don't understand why the L1 is 4 cycles instead of 3. I REALLY don't
>understand why the L2 cache is so slow (20 cycles, really??), because size alone
>doesn't account for it. 12-14 cycles sounds much more reasonable.
>
>The L3 cache is also quite slow, in part because of the slow L2 and in part because
>it runs at asynchronous to the cores. If you look at those two factors together
>and assume a 14 cycle L2, you can probably cut the L3 latency down by ~10 cycles.
>
>
>DK
>

Good points. But isn't BD mostly asynchronous or semi-synchronous ?

IIRC from HotChips, those *vertical domains* after fetch, which has 2 IBB is decoupled and can go ahead or o-o-o, only execute from 1 thread at a time : fetch/branch domain decoupled & asynchronous <-> decode domain <-> dispatch domain <-> exec decoupled & asynchronous except the FPU front-end

http://techreport.com/r.x/bulldozer-uarch/bulldozer-thread-control.jpg

Isn't this asynchronous very difficult to accomplish efficiently compared to a source to sink synchronous pipeline (or even the common o-o-o) ?... i suspect BD module is prepared to have more easily more threads per module, than the SMT style of Intel can have threads per core.

Perhaps BD have oddities because it was *very* difficult to come by, and if in the future there will be 4 or 6 threads per module, than there are good reasons for betting on the design, after all BD already employs about every basic multithreading scheme i remember: SMP,SMT, Switch-on-event, vertical multithreading ...