Hacker News Reader

Comment by johnklos | Hacker News Reader

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.

View on HN

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.

> 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

Good for you, you actually use a workstation for its intended purpose. You would be surprised how rare that is.

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.

Putting the memory dies on a substrate die alongside the CPU and GPU dies will, however.

A lot of core functionality like dealing with zip files hasn't been updated for modern times, and doesn't support multiple cores. So it's likely you're using just one core to uncompress stuff.

sure, if you have a modern system with plenty of ram and ssd, then cpu will still be a bottleneck.

what i am saying is that if given a choice of a brand new cpu with 8gb ram and a hard drive (common specs for 10 years ago) or a 10 year old cpu with 16gb ram and an ssd, then i would definitely take the 10 year old cpu.

case in point, i recently bought this super cheap dell laptop, which has a really nice brand new cpu (i5-1135G7) but only 8gb ram and a crappy ssd. i will upgrade those things when i have the time, but right now if i am running too many things it will start swapping out, and that is far worse than maxing out the cpu.

I agree and I also think the timing of it's release helped as well. It came out about a year before the new Xbox and Playstation consoles were released and which were both using AMD silicon. So from a gaming perspective it was passable.

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.

It was fine because both consoles have underpowered CPU (but 8 cores) for manufacturing reason, so PC gaming also don't need strong CPU

I'm assuming you're talking about PS4 and Xbox One. If so, they used a much simpler and lower-power architecture than Bulldozer that was initially intended for netbooks and tablets.

https://en.wikipedia.org/wiki/Jaguar_(microarchitecture)

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

You must be the beneficiary of very cheap electricity.

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.

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

These were interesting results then, but I think code generation and OSes have evolved enough that current compiles on a current OS with a current toolchain are actually faster on an FX-8150 than on an i5 of the age from those results.

Even from the time that Ryzen first came out until now, OSes have been improving threading, reducing contention, et cetera, to noticeable degrees.

Tell you what - when I'm back on the coast that has my older machines, I'll run some modern compiles on a quad i5 of that era and on my FX-8150, and we'll see. If nothing else, perhaps it'll be interesting to see how much threading performance has improved in the last decade.

BTW - I did do side-by-side testing back then between the quad i7 and the FX-8150, and the results were certainly not as clear cut as these. Then again, I wasn't building a huge, barely portable source tree with -J 8 like Chromium - I was building many separate things in parallel at the same time. The cost is what ultimately tipped me in favor of AMD.

Not everyone who bought AMD then was necessarily a fanboi, and I'd point out that people who were fans of the Ryzens when they were new often liked both how they were very favorably priced compared with anything Intel, plus how we were assured that later Ryzens would work in our then current motherboards. Having just replaced a Ryzen 2600 with a Ryzen 5700X and seeing overall power usage go down, I'd have to disagree with your early Ryzen sentiment.

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 ?

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.

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.

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

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

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

Reply on news.ycombinator.com