>>Or maybe by memory subsystem you mean the load/store units themselves? Because
>>that is indeed where BD has improved. If this is what you mean then I think we have a communication problem.
>
>I mean the load/store units, L1, L2, L3, memory, prefetchers and everything that
>goes on the middle, everyone else seens to just look at L1 size, L2 latency, L3 latency and memory latency.
>
>>But why would the performance impact be limited to
>>only the execution width or the memory subsystem and never both?
>
>Well... There are some integer workload were BD is actually faster than GH by a
>significant amount, from were the performance gains come?
>
>These workloads happens to be memory intensive...

These are the memory-intensive workloads where Bulldozer's prefetcher work well.

It seems bulldozer "trusts too much in it's aggressive prefetchers".
When they work well, it's getting data from memory nicely on time and cache hits are rare, so average memory latency is low and performance is good.
Your memory-intensive workloads fit into this category.

The Sun/Oracle JVM developers disabled software prefetch instruction generation when the JVM is ran on bulldozer because bulldozer's hw prefetcher did better job than they could do with their prefetch instruction inserter.


But when the access patterns are too complex that the prefetcher cannot prefect correct data to be prefetcher, then the slow L2 and L3 cache latencies start to have a heavy tax.

And this is often the case with workloads that are not "so memory-intensive", ordinary code sometimes loading something unexpected. So the slow L2/small L1-combination penalizes "average code", not "memory-intensive" code.

And sometimes the prefetchers think they are smarter than they truely are, and start prefetching thing that are not really used, wasting L2/L3/memory bandwidth.