David Kanter (dkanter@realworldtech.com) on 4/20/12 wrote:
---------------------------
>It's very hard to measure that without using any performance analysis tools. I
>don't disagree that it's a significant hit in performance, but quantifying that is challenging.

Premise: I don't have a Bulldozer chip for testing, so my analisys is based on public results. To me, it seems that ALU performance are quite OK, with < 10% performance loss in some synthetic test:
http://www.ilsistemista.net/index.php/hardware-analysis/24-bulldozer-vs-sandy-bridge-vs-k10-comparison-whats-wrong-with-amd-bulldozer.html?start=5

Also 7-zip decompress benchmark is a strong point of Bulldozer uarch (in comparison to K10.5 cores), denoting higi ALU/memory performance.

>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.

Yes, L1 is 4 cycles, but Nehalem has similar L1 latency, yet performs very well. I think that the real problem is the L2: while WCC absorb some latency, the throughput is badly affected by L1 WT desing. Moreover, it seems to me that, while the module's L2 partition has 2xR + 2xW bus, they are only 64 bit wide (compared to Intel design, this is quite low, especially considering single-thread cases).

Some results:
http://www.ilsistemista.net/index.php/hardware-analysis/24-bulldozer-vs-sandy-bridge-vs-k10-comparison-whats-wrong-with-amd-bulldozer.html?start=4

>The fact that the L1 is write through is totally irrelevant to latency and should
>actually improve things because AMD got rid of ECC on the L1. The stores go directly
>to the 4KB write combining cache and then written back to the L2 on a deferred basis.
>
>http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=9
>

This is true, but the WCC is only 4 KB in size and it can absorbs only limited amount of writes before coalesce them to L2.

>>I still believe BD's biggest problem is its cache >latencies, but the chip as it
>>shipped last year is a badly flawed piece of work.
>
>I think the cache hierarchy overall is definitely one of the biggest culprits.
>Hopefully they will fix things in the future.
>
>DK

I agree. Let see Piledriver...

Regars.