Bulldozer, AMD’s Crash Modernization: Front End and Execution Engine

Conversely, the Cell took this too far, requiring that high level software be deeply SPE and memory-shuffling aware, almost like having a bank of DSPs in-package. The instruction-set/functional difference between the PPE and SPE made for encumbrances that likely would never have been fully solved by the toolchain (even if the toolchain had shipped ahead of the processor rather than well afterwards).

Larrabee made attempts to solve the instruction set difference problem (in a very Intel way), but the topology, cache behavior, and pure core size proved to be far too limiting in real applications. In the end, Intel missed on the balance of core/execution-unit size vs. count when compared to Nvidia and ATI. GPGPU progress has definitely demonstrated the value of toolchain abstraction, though, and adherence to a given instruction set (and the architectural implications that came from that) proved to be a limiting constraint for Larrabee.

The last 20-25 years in compute architecture design have seen many interesting articulations of clever ideas. Some deaths were predictable, but each of the explorations should be commended for the ways that they pushed boundaries and cleared the path for their successors.

In older SSE architectures, memory alignment and register-to-register result latencies sometimes made it easier/better to stride operations on partially-masked registers rather than reorganize the data. With high architectural register counts and newer shuffling instructions, that need is lower.

Definitely avoid branching in tight compute code, though. Branching kills performance, sometimes in very data-dependent and annoying ways.

This drives me insane, literally every day my computer spends minutes - likely hours in total in a day - blasting at 100% CPU and it's not a ten years old one. Hell, I got access to a threadripper 5990X and even that one I sometimes end up in situations where I have to wait for CPU operations to finish, even for basic life things such as uncompressing archives or editing pictures so I really cannot understand

It could run last gen console ports well and didn't struggle much with next gen. I had a FX-8320E that was used almost exclusively for gaming and it was fine.

but the integer cores shared a frontend which alternated between feeding the two cores, so using all 8 threads (2 threads per module) reduced per-thread performance even further from the already abysmal 1TPM performance levels.

The FX-8150 failed to outperform a 2500K in compiling let alone a 2600K. In fact it was significantly slower than a Phenom II X6, which was much closer to the 2600K while the FX-8150 failed to even match the 2500K.

https://images.anandtech.com/graphs/graph4955/41699.png (may need to hit enter or open-in-private-window to force a referrerless load)

You can see how hard that shared frontend hits - Phenom with 6 "modules" curbstomps the Bulldozer in compiles despite having "fewer threads". It's not just that Bulldozer IPC is bad per-thread and it's made up with more threads, using more threads actually causes further reductions of the IPC which destroy a lot of the benefits of having those threads in the first place. It was not a good processor even in heavily multithreaded loads, outside some happy cases.

Frankly there was just as much of a fanboy effect in those days as in the early days of Ryzen, which really wasn't justified by the actual performance. Most actual productivity loads used AVX which strongly favored Intel over Ryzen due to the half-rate AVX2, the 5820K did great in those workloads for a very affordable price and was also much better in gaming/etc, plus had massive overclocking headroom. But people tend to laser-focus on the handful of very specific workloads Ryzen 1000 did OK at. Intel was generally much more potent per-core if you did video encoding, for example, or in later Cinebench variants that used AVX. But Ryzen looked real good in pre-AVX cinebench R11.5 and R15 so that's what people cited.

People bought Bulldozer because they had always bought AMD and that was the brand they identified with on a social level. It was a terrible product and only slightly mitigated by the Piledriver series (FX-8350)... which had to go up against Ivy Bridge and later Haswell, where it was just as far behind.

https://images.anandtech.com/graphs/graph6396/51121.png

Same story as Phenom. Bulldozer would have been a competitive product if it got to market 2 years earlier and didn't need another couple years to fix the deficiencies.

https://www.agner.org/optimize/microarchitecture.pdf

I wouldn't say there are issues with sharing those components. More that the non-shared parts were too small, meaning Bulldozer came up quite short in single threaded performance.

Long story short, running two threads with only enough hardware to run just one at full speed means any thread that tries to run at full speed will not be able to.

Just as with any other debt, the cost in the long term must be balanced against the needs of the short term. And as with any other debt, if someone takes on that debt and then decides to ignore repayment there will be much wailing and gnashing of teeth when the bill comes due. ;)

It reminds me of the myth of Cassandra.

But I guess $12M is just the high end of nuisance money for AMD.

this has always been a massive oversimplification and misrepresentation from the AMD fanclub. the case was decided because of shared resources including the L2 and the frontend (fetch-and-decode, etc) which very legitimately do impact performance in a way that "independent cores" do not.

Citing the actual judgement:

> Plaintiffs allege that the Bulldozer CPUs, advertised ashaving eight cores, actually contain eight “sub-processors” which share resources, such as L2 memory caches and floating point units (“FPUs”). Id. ¶ 37–49. Plaintiffs allege that the sharing of resources in the Bulldozer CPUs results in bottlenecks during data processing, inhibiting the chips from “simultaneously multitask[ing].” Id. ¶¶ 38, 41. Plaintiffs allege that, because resources are shared between two “cores,” the Bulldozer CPUs functionally only have four cores. Id. ¶ 38–43. Therefore, Plaintiffs claim the products they purchased are inferior to the products as represented by the Defendant. Id. ¶ 39

This is completely correct: the chip only has one frontend per module which has to alternate between servicing the two "cores" and this does bottleneck their independent operation. It is, for example, not the same thing as a "core" used on Phenom and this significantly impacts performance to a hugely negative extent when the "second thread" is used on a given module.

It's fine to do it, this same approach is used in SPARC for example, but SPARC doesn't market that as (eg) a "64 core processor", they market it as "8 cores, 64 threads". But AMD wanted to have the marketing bang of having "twice the cores" as intel (and you can see people representing that even in this thread, that programmers bought AMD for compiling because "it had twice the cores", etc). And that is not how anyone else has marketed CMT before or since, because it's really not a fair representation of what the hardware is doing.

Alternately... if that's a core then Intel is definitely a core too, because basically CMT is just SMT with some resources pinned to specific threads, if you want to look at it like that. After all where is the definition that says an integer unit alone is what constitutes a core? Isn't it enough that there are two independent execution contexts which can execute simultaneously, and isn't it a good thing that one of them can use as many resources as possible rather than bottlenecking because of an execution unit "pinned" to another thread? If you accept the very expansive AMD definition of "core" then there's lots of weird stuff that shakes out too, and I think consumers would have found it very deceptive if Intel had done that like AMD, that’s obviously not what a “core” is, but it is if you believe AMD.

AMD did a sketch thing and got caught, end of story. No reason they should call it anything different than the other companies who implement CMT.

I hate hate hate the "AMD got skewered because they didn't have an FPU" narrative. No, it was way more than the FPU, and plaintiffs said as much, and it's completely deceptive and misrepresentative to pretend that's the actual basis for the case. That's the fanclub downplaying and minimizing again, like they do everytime AMD pulls a sketchy move (like any company, there have been a fair few over the years). And that certainly can include El Reg too. Everyone loves an underdog story.

Companies getting their wrists slapped when they do sketchy shit is how the legal system prevents it from happening again and downplaying it as a fake suit over crap is bad for consumers as a whole and should not be done even for the “underdog”. The goal shouldn’t be to stay just on the right side of a grey area, it should be to market honestly and fairly… like the other companies that use CMT did. Simple as.

To wit: NVIDIA had to pay out on the 3.5GB lawsuit even though their cards really does have 4GB. Why? Because it affected performance and the expectation isn't mere technical correctness, it's that you stay well on the right side of the line with your marketing's honesty. It was sketch and they got their wrist slapped. As did AMD.

It didn't help that it was also time when Intel was at top of their game, still pushing significant single-thread perf improvements. Sandy Bridge, which was Bulldozers main competitor, was exceptionally successful launch on its own right

For some years, and especially during the last six months before the Bulldozer launch in 2011, AMD has continuously made various claims about its performance, always stressing that it will crush Sandy Bridge, due to having a double number of "cores".

Immediately after launch, all the AMD claims were proved to be shameless lies. There is absolutely no excuse for AMD. Intel had published accurate information about the performance of Sandy Bridge, one year in advance. Even without the advance publication, the performance of Sandy Bridge could have been easily extrapolated from the evolution of Penryn, Nehalem and Westmere.

The performance of Bulldozer was determined by design decisions taken by AMD at least 3 to 4 years before its launch. Therefore, during the last 6 months, when they have lied the most, they knew perfectly well that they were lying and it should have been obvious to them that this is futile, because the lies will be exposed by independent benchmarks immediately after launch.

For most operations, a so-called Bulldozer "module" (with 2 "cores") had exactly the same execution resources as a Sandy Bridge core, while for a few operations, like integer multiplication, a Bulldozer "module" had even less execution resources than a Sandy Bridge core.

The common FPU of 2 Bulldozer "cores" was more or less equivalent with the FPU of a single Sandy Bridge core.

The Bulldozer integer "cores" were stripped down in comparison with the cores of the previous AMD CPUs, e.g. a new "core" had 2/3 of the addition throughput and 1/2 of the multiplication throughput of an old core.

So 2 Bulldozer integer "cores" were together barely faster than one old AMD core, while a single Sandy Bridge core was faster than them, by having an equal addition throughput, but a double multiplication throughput.

Bulldozer could have been a decent CPU, if only AMD, instead of describing it as a 4-"module"/8-"core" CPU, would have described it as a 4-core/8-thread CPU, which matched Sandy Bridge, except that in Sandy Bridge the 2 threads of a core shared dynamically most execution resources, while in Bulldozer only a part of the execution resources were shared dynamically, e.g. the FPU, while the rest of the execution resources were allocated statically to the 2 threads of a core, which is less efficient.

Such a description would have set correctly the expectations of the users, and they would not have felt cheated.

I am pretty certain that the huge disappointment that has accompanied the Bulldozer launch has hurt much more the AMD sales than they might have gained from the buyers lured by the false advertising about the 8-core monster AMD CPUs, which should easily beat the puny 4-core Intel CPUs.