8 ms·

I remember deliberating between AMD's eight core FX-8150 and the latest Intel Sandy Bridge in early 2012. Even though lots of people consider Bulldozer to be a

I remember deliberating between AMD's eight core FX-8150 and the latest Intel Sandy Bridge in early 2012. Even though lots of people consider Bulldozer to be an AMD misstep, I don't regret my choice: AMD's eight integer cores performed favorably compared with the four real cores plus four hyperthreads of the Intel. Considering I bought it to be used primarily for compiling, it was a good choice. This is an interesting read, and seeing the design choices with knowledge of how things turned out later makes it even more interesting.

BlueTemplar 4y ago
I am still using a FX-8xxx (and probably will until RISC-V will beat it), and haven't even bothered overclocking it yet. Anyone knows what kind of issues having "The frontend, FPU, and L2 cache [] shared by two threads" causes compared to 2 real cores / 2 hyper threads on 1 core / 4 hyper threads on 2 cores ?
- Dalewyn 4y ago
  My ELI5 understanding is it's a problem of throughput and resource availability. 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.
  - deaddodo 4y ago
    It would work fine with double integer loads, or heavily integer based work with the occasional FPU necessity. The problem wasn't throughput as much as the latter: it didn't have enough FPU resources and would get deadlocked waiting on availability; so would behave in the worst case (as a single core) more often than not.
    - paulmd 4y ago
      The problem isn't execution unit throughput at all, it's decode, where running the second thread on the module would bottleneck the decoder and force it to alternate between servicing the two threads. And this doesn't really matter what is running on the other core, it simply cannot service both cores at the same time regardless of instruction type even if the first core isn't using all its decode. If it has to decode a macro-op, it can even stall the other thread for multiple cycles. > Each decoder can handle four instructions per clock cycle. The Bulldozer, Piledriver and Excavator have one decoder in each unit, which is shared between two cores. When both cores are active, the decoders serve each core every second clock cycle, so that the maximum decode rate is two instructions per clock cycle per core. Instructions that belong to different cores cannot be decoded in the same clock cycle. The decode rate is four instructions per clock cycle when only one thread is running in each execution unit. ... > On Bulldozer, Piledriver and Excavator, the shared decode unit can handle four instructions per clock cycle. It is alternating between the two threads so that each thread gets up to four instructions every second clock cycle, or two instructions per clock cycle on average. This is a serious bottleneck because the rest of the pipeline can handle up to four instructions per clock. > The situation gets even worse for instructions that generate more than one macro-op each. All instructions that generate more than two macro-ops are handled with microcode. The microcode sequencer blocks the decoders for several clock cycles so that the other thread is stalled in the meantime. https://www.agner.org/optimize/microarchitecture.pdf https://www.agner.org/optimize/microarchitecture.pdf
- clamchowder 4y ago
  (author here) With hyperthreading/SMT, all of the above are shared, along with OoO execution buffers, integer execution units, and load/store unit. 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.
- paulmd 4y ago
  Read the "bottlenecks in bulldozer" section, particularly the parts about instruction decode (never say x86 doesn't have any overhead) and instruction fetch. Or see the excerpt I posted below. https://www.agner.org/optimize/microarchitecture.pdf https://www.agner.org/optimize/microarchitecture.pdf
metalspot 4y ago
i used an fx-6300 for years and it was fine. for most use cases the practical need for desktop cpu performance plateaued 10 years ago. during that time adding more memory and moving from hdd to ssd made a much larger difference in user experience than increasing the cpu performance. the biggest problem for amd was not the architecture of the cpu, but the lack of integrated graphics on high end parts, and power efficiency on mobile. both of which were caused by being stuck on an older process. it's also worth remembering that internally amd had a grand vision of unifying the cpu and gpu (HSA) which would have added a bunch of fp compute to the integrated chip, but that vision required a lot of other things to go right, and a lot of them went wrong, so it never happened.
- jcelerier 4y ago
  > for most use cases the practical need for desktop cpu performance plateaued 10 years ago 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
  - MobiusHorizons 4y ago
    Good for you, you actually use a workstation for its intended purpose. You would be surprised how rare that is.
  - projektfu 4y ago
    High memory use will still peg a CPU at 100%. They don't get many opportunities to do other things while waiting for cache refills. Increasing core speed/single thread performance will not help much in memory-bound tasks.
    - Accujack 4y ago
      Putting the memory dies on a substrate die alongside the CPU and GPU dies will, however.
digitallyfree 4y ago
I had a programmer friend who got the FX-8150 in 2012 for compiling - pricewise it was basically equivalent to a i5 but you got 8 integer cores in return. It's a decent choice if you prioritize core count over single-core/FP performance. Efficiency wise those desktop CPUs were space heaters, with the FX-9590 coming to mind. Pre-Zen laptops were also notorious for poor battery life.
- paulmd 4y ago
  > I had a programmer friend who got the FX-8150 in 2012 for compiling - pricewise it was basically equivalent to a i5 but you got 8 integer cores in return. 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 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 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.
rjsw 4y ago
I am still using a six core Bulldozer as my main development machine, still happy with my choice. For compiling stuff it works well.
- selectodude 4y ago
  You must be the beneficiary of very cheap electricity.

BlueTemplar 4y ago

I am still using a FX-8xxx (and probably will until RISC-V will beat it), and haven't even bothered overclocking it yet. Anyone knows what kind of issues having "The frontend, FPU, and L2 cache [] shared by two threads" causes compared to 2 real cores / 2 hyper threads on 1 core / 4 hyper threads on 2 cores ?

Dalewyn 4y ago
My ELI5 understanding is it's a problem of throughput and resource availability. 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.
- deaddodo 4y ago
  It would work fine with double integer loads, or heavily integer based work with the occasional FPU necessity. The problem wasn't throughput as much as the latter: it didn't have enough FPU resources and would get deadlocked waiting on availability; so would behave in the worst case (as a single core) more often than not.
  - paulmd 4y ago
    The problem isn't execution unit throughput at all, it's decode, where running the second thread on the module would bottleneck the decoder and force it to alternate between servicing the two threads. And this doesn't really matter what is running on the other core, it simply cannot service both cores at the same time regardless of instruction type even if the first core isn't using all its decode. If it has to decode a macro-op, it can even stall the other thread for multiple cycles. > Each decoder can handle four instructions per clock cycle. The Bulldozer, Piledriver and Excavator have one decoder in each unit, which is shared between two cores. When both cores are active, the decoders serve each core every second clock cycle, so that the maximum decode rate is two instructions per clock cycle per core. Instructions that belong to different cores cannot be decoded in the same clock cycle. The decode rate is four instructions per clock cycle when only one thread is running in each execution unit. ... > On Bulldozer, Piledriver and Excavator, the shared decode unit can handle four instructions per clock cycle. It is alternating between the two threads so that each thread gets up to four instructions every second clock cycle, or two instructions per clock cycle on average. This is a serious bottleneck because the rest of the pipeline can handle up to four instructions per clock. > The situation gets even worse for instructions that generate more than one macro-op each. All instructions that generate more than two macro-ops are handled with microcode. The microcode sequencer blocks the decoders for several clock cycles so that the other thread is stalled in the meantime. https://www.agner.org/optimize/microarchitecture.pdf https://www.agner.org/optimize/microarchitecture.pdf
clamchowder 4y ago
(author here) With hyperthreading/SMT, all of the above are shared, along with OoO execution buffers, integer execution units, and load/store unit. 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.
paulmd 4y ago
Read the "bottlenecks in bulldozer" section, particularly the parts about instruction decode (never say x86 doesn't have any overhead) and instruction fetch. Or see the excerpt I posted below. https://www.agner.org/optimize/microarchitecture.pdf https://www.agner.org/optimize/microarchitecture.pdf

metalspot 4y ago

i used an fx-6300 for years and it was fine. for most use cases the practical need for desktop cpu performance plateaued 10 years ago. during that time adding more memory and moving from hdd to ssd made a much larger difference in user experience than increasing the cpu performance. the biggest problem for amd was not the architecture of the cpu, but the lack of integrated graphics on high end parts, and power efficiency on mobile. both of which were caused by being stuck on an older process. it's also worth remembering that internally amd had a grand vision of unifying the cpu and gpu (HSA) which would have added a bunch of fp compute to the integrated chip, but that vision required a lot of other things to go right, and a lot of them went wrong, so it never happened.

jcelerier 4y ago
> for most use cases the practical need for desktop cpu performance plateaued 10 years ago 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
- MobiusHorizons 4y ago
  Good for you, you actually use a workstation for its intended purpose. You would be surprised how rare that is.
- projektfu 4y ago
  High memory use will still peg a CPU at 100%. They don't get many opportunities to do other things while waiting for cache refills. Increasing core speed/single thread performance will not help much in memory-bound tasks.
  - Accujack 4y ago
    Putting the memory dies on a substrate die alongside the CPU and GPU dies will, however.

digitallyfree 4y ago

I had a programmer friend who got the FX-8150 in 2012 for compiling - pricewise it was basically equivalent to a i5 but you got 8 integer cores in return. It's a decent choice if you prioritize core count over single-core/FP performance. Efficiency wise those desktop CPUs were space heaters, with the FX-9590 coming to mind. Pre-Zen laptops were also notorious for poor battery life.

paulmd 4y ago
> I had a programmer friend who got the FX-8150 in 2012 for compiling - pricewise it was basically equivalent to a i5 but you got 8 integer cores in return. 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 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 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.

rjsw 4y ago

I am still using a six core Bulldozer as my main development machine, still happy with my choice. For compiling stuff it works well.

selectodude 4y ago
You must be the beneficiary of very cheap electricity.