Personally I don't see the shared front end as being the major problem with the BD design. Intel shares the frontend between two threads too, and it has sort of similar width. If you're using one thread significantly more than the other (or dedicating the module to one thread exclusively) the shared nature shouldn't hurt you, so long as the scheduling between the two favors the more important one. Of course it doesn't help when AMD thinks it's better not to schedule threads together on a module if they can help it, and has to change that later..

In other words, that 10-20% or whatever is the cost of running two threads on one module vs two modules, not the cost of running one thread on the module. And since AMD is delivering just as many "full" cores and threads as Intel is at the same market segments (more really, if you consider that Intel doesn't enable HT in the mid-range) this isn't really the problem. Fairly little right now benefits from full time threading on > 4 cores and these are the workloads AMD actually does well at.

That's not to say the frontend doesn't have weaknesses. The instruction cache should have more associativity for sure, 2-way vs 8-way for Intel is going to be a big problem on some workloads. And the decoders can be tripped up by big flaws too, like only being able to handle one double path instruction per cycle, instead of the two you would expect. This makes the decode rate for a stream of AVX instructions choke on it, for instance - and since decode is in-order this is an easy place for fragility to be exposed. Same reason Intel naturally improved a lot with its 3-1-1 style decode patterns, when fused uops made the simple decoders much more powerful.

But I think the real problem with BD is in the cores themselves and memory hierarchy. Saying that it's merely "two ALUs" obscures the real execution width. If you could only do two simple ALU operations but could do other types of operations simultaneously it'd probably be a lot better off. But it doesn't just shove ALU operations through the two EX ports, but multiplies, branches, and stores must take one of them too. It doesn't look like the AG ports handle much else besides address generation (including loads) and inc/dec.

This creates a balance problem that's really astonishing.. I don't know much about chip design, so someone please tell me if I'm saying something stupid, but it seems like you put in a lot of circuitry in the register file and forwarding network to be able to accommodate 4 execution units simultaneously. Isn't it then a huge waste to make a couple of them capable of almost nothing? Seems like those AGLU ports should at least be capable of basic ALU operations and moves, considering their namesake. I wonder if this was the intention and it somehow got axed. At least Piledriver is supposed to extend them to include simple reg/reg moves, as well as some obscure instructions (XADD and BEXTR.. seriously? No idea what they're thinking here)

And the write-through cache doesn't hurt them on principle, but they're probably being burned by it because of the low L2 bandwidth. The WCC would presumably help a lot here if you're dealing with a lot of consecutive small (or at least, 32 or 64-bit sized) stores, but it might really be so bad that it's not enough.

The L2 latency does look high, and we know that if you halve the size to 1MB the design only allows taking it down to 18 cycles, so it's not dominated by size. I think the problem here is that AMD wants to accommodate huge frequencies. Aside from the problem that they don't have the power/thermal budget for those frequencies it suggests conflicting design goals. On the one hand AMD wants it to be able to turbo up for high single threaded performance - but they also want to cram a bunch of cores into a chip and let them run at full tilt. And since it's optimized for server workloads (high cache) that means it's also optimized for running a lot of cores without a lot of room leftover for turbo most of the time - so it ends up being good for low clocks but paying the design price for high clocks. Same with their goals in mobile, which are probably going to be their biggest markets in terms of chip volume - do you think those 17W-35W Trinity chips are going to benefit from a design that can turbo to 5GHz? Probably not very often.

So the whole high clock goals seem like an effort to gain a respectable halo product, but without actually coming close enough in single threaded performance vs Intel to look respectable. Should have cut their losses here and focused on throughput and low power, IMO.