I suspect the improvements are even more dramatic going from Zen 1 through to Zen 5. AMD has really hit the jackpot with how scalable the Ryzen CPU is considering how they're able to improve the performance from year to year. This is a stark difference to the FX series during the 2010s, which saw very small YoY performance increases by comparison. Ryzen really is AMD's equivalent to what Nehalem/Core was for Intel back in the mid 2000s.
That is all true but I will defend the FX series a little. Mostly now that there is a lot of software that scales across cores better now, they haven't aged as terribly as others have. They aren't great but not terrible considering.
>Mostly now that there is a lot of software that scales across cores better now
That's pretty much irrelevant since the AMD's FX arch's issues weren't that SW at the time wasn't using all the 8 cores. Intel dropped the Core 2 Duo and Quad into the era where most SW was still stuck in single threaded for a long time and those CPUs still ripped single-threaded SW tasks regardless.
Here's the big reasons why the FX sucked back then and why they still suck today in the multi-thread SW era:
Instead of discrete, fully independent cores, AMD grouped processing units into "Modules" where each module contained two integer execution units, but they had to share critical resources like one FPU, the instruction fetch/decode pipeline, and the L2 cache so when both "cores" inside a module were heavily taxed especially with math or physics-heavy calculations (like in videogames), they choked fighting over shared hardware.
AMD designed Bulldozer with a very long pipeline, betting they could sacrifice efficiency per clock cycle in exchange for extraordinarily high clock speeds(a-la Intel Pentium 4) but the IPC was so bad that an FX core was often slower clock-for-clock than AMD’s previous-generation Phenom II chips and also their power consumption exploded.
FX processors were plagued by high cache latencies and an inefficient memory subsystem as another bottleneck.
So unless you're into collecting vintage CPUs as display pieces, this one definitely belongs in the e-waste pile instead of burning electricity, because it did not age like wine with the adoption of SW multi threading like people were hoping.
> AMD designed Bulldozer with a very long pipeline, betting they could sacrifice efficiency per clock cycle in exchange for extraordinarily high clock speeds
It blows my mind that AMD watched Intel try to do basically the same thing only a few years prior with NetBurst, and fail so badly that they had to scrap that entire evolutionary branch and start over – and AMD still went and did it again themselves anyway.
I remember rumblings a decade-ish ago that basically their hand was possibly forced to release the thing to avoid a full on revolt about abandoning all of their work; after all, Intel had been investing in deep pipelines for a while before, they were strapped for cash after the ATI Acquisition, and other 'server-ish' CPUs had done CMT type things in the past (keeping in mind that AMD was seeing a huge surge in server market share due to Hammer.)
Hyperthreading/SMT is a significant boon for heavily threaded workloads. What makes that such a win while Bulldozer's implementation of "two integer units sharing a front-end, cache and FPU" is supposedly so bad? Because that description makes the 8 core Bulldozers sound exactly like a 4 core with SMT.
>Hyperthreading/SMT is a significant boon for heavily threaded workloads.
That's hugely debatable and depends on SW workloads and the SMT implementation + CPU pipeline design.
In SMT the execution engines, ALUs, FPUs, and caches are completely shared. When one thread stalls waiting for RAM, the second thread sneaks into the idle execution units. At best, SMT yields a ~10% to 20% throughput boost over a single thread.
>Because that description makes the 8 core Bulldozers sound exactly like a 4 core with SMT.
It's not the same thing. Bulldozer arch sits between a true 8-core and 4-core + SMT implementation.
> At best, SMT yields a ~10% to 20% throughput boost over a single thread.
Exactly, which is a significant benefit for how marginal the costs are.
> It's not the same thing. Bulldozer arch sits between a true 8-core and 4-core + SMT implementation.
Then surely it should be even better than 4 cores with SMT?
If you're going to argue that the problem with Bulldozer was it's weird semi-SMT solution, you need to explain how it would've been better without it (aka as a regular quad core). Because even if it just gets the 10-20% performance improvements from being a form of SMT it would be better to have it than to not. And if you have lots of integer unit-bound threads, it should be even better than that.
>Then surely it should be even better than 4 cores with SMT? If you're going to argue that the problem with Bulldozer was it's weird semi-SMT solution, you need to explain how it would've been better without it
I explained all the bottlenecks of the architecture in a comment above, that the issue was more than 4-core +SMT instead of true 8 cores. Please read it.
I did read it. It's not clear from it why you think having 2 integer units per core in a SMT-like configuration makes it worse. If you have <=4 threads it doesn't matter, just schedule the threads on different proper cores. If you have >4 memory/FPU/front-end heavy threads you should see the same benefit as SMT. If you have >4 integer arithmetic-bound cores, you should see a significant benefit beyond what SMT would give.
Now the very long pipeline and high memory latency are obviously significant issues with the architecture but those seem disconnected from the 4-core+SMT issue? I'm not questioning those issues at all, it's just not the part of your comment which interested me
EDIT: okay so in this comment: <a href="https://news.ycombinator.com/item?id=49809017">https://news.ycombinator.com/item?id=49809017, you explain that there's actually a fairly large part of a core that's duplicated, not just two integer units. If each "core" gets its own integer unit, register file and L1 cache, you're actually paying a ton of die space for it, unlike SMT which is "free". I can totally get how that can be a terrible trade-off for most workloads if it all ends up mostly starved due to front-end/FPU/memory throughput.
Well, 'core' gets weird when we talk about Dozer. And where everything else had problems making it work.
AFAIR, a bulldozer 'module' has what is exposed to a core as two CPUs, but, per everything above, is two integer cores, one shared FPU core, and depending on the version of the arch, possibly shared fetch/decode/other resources between all of that. Also AFAIR the decoder sucked as far as being able to feed both the integer cores, and the integer cores were more anemic compared to what was in, say, a K10H Phenom.
Sorry, I edited my comment while you were writing. I had missed that it's more than just "one core with two ALUs". The more silicon you dedicate to this almost-but-not-quite-SMT solution, the worse of a trade-off it becomes in situations which don't benefit from it, and it sounds like quite a lot of silicon was dedicated.
Your theory that "1 shared FPU per module should equal 1 shared FPU per SMT core" makes sense on paper, but Bulldozer lost to Intel’s Sandy Bridge 4C/8T in floating-point and memory-heavy workloads because Intel's individual FPU, cache hierarchy, and front-end pipelines were vastly wider and faster than Bulldozer's shared components.
Having the same count of units (4 FPUs on the chip) did not mean having the same throughput. It's a HW bottleneck, not something AMD could fix via the OS's kernel allocation and scheduling of resources to the CPU to be able match Intel.
In strictly integer 4-8 thread benchmarks, yeah, AMD was often tied to Intel's 4C+SMT.
Bulldozer’s design didn't lose because the concept of sharing an FPU between two threads is worse than SMT. It lost because:
Intel's FPU was natively twice as wide (256-bit vs. split 128-bit).
AMD's write-through L1 cache caused catastrophic write contention in L2.
AMD's L2 and L3 caches had double to triple the access latency of Intel's.
A single shared 4-wide decoder couldn't feed an FPU and two integer units simultaneously.
Wait but this new list of things you claim made Bulldozer lose is different from the previous list of things you claim made Bulldozer lose, and the "two integer pipelines per core" thing is no longer a part of it. You're also responding argumentatively to my conciliatory comment.
This is exactly the kind of thing I've seen ChatGPT do way too much FWIW, arguments silently change after push-back without acknowledgement. I think you're either a bot, or (more embarrassingly) using ChatGPT to formulate your arguments.
AFAIR Steamroller was a big 'correction' of the Shared resource issues in the arch (I can't remember if other revisions had other improvements).
AMD was also having to deal with the fact GloFo split off and was relying more on general 'bulk' lithography, which kneecapped them for some time especially due to yield issues on the FX series and overall cost of that deal.
Intel also very quickly after, released Sandy Bridge and aggressively scaled it up and down; the 2500K was so cheap yet powerful I know of at least one setup that ran for a decade an only got replaced because they needed to upgrade to windows 11 for compliance-esque reasons. My own 2500K I replaced in 2017-2018-ish, only because either the motherboard took an unfortunate dive and it was easier to replace both at once.
FWIW, I did do a cheapie FX build in 2015ish for my then-girlfriend as a DVR and light gaming/emulation 'under the TV box', and it did the job well for the price, but it definitely wasn't anything amazing.
It was a tough time for AMD for sure. I think the 'split' between the Cat cores (Bobcat/Jaguar) also hurt them from a resource standpoint, although one could argue that it also kept them alive to recover (i.e. Jaguar in XBox One and PS4 being a volume contract part) [0]. They did a lot of moves that caused short term pain (that glofo spinnoff helped pay off the ATI Acquisition AFAIR) but helped them become the company that is still surviving today.
[0] - One odd side note, I still find it odd that they never did a dual channel Jaguar laptop part. I still ask whether it was because it would have made the FX look that bad...
> Instead of discrete, fully independent cores, AMD grouped processing units into "Modules" where each...
Yeah that's hyper-threading intel was doing it as well and all modern CPUs do it as well. Where AMD dropped the ball, was they did not disclose that in their marketing as clearly as they should.
All CPUs today are marketed as x cores 2x threads, back then some AMD marketing genius in their infinite wisdom put 8 cores on the box, instead of the honest 4 cores with hyperthreading.
No, AMD's FX "fake" 8-core was more than just 4-cores + hyperthreading. In SMT(hyperthreading) the execution engines, ALUs, FPUs, and caches are completely shared, whereas on FX design, they built two completely separate integer pipelines (schedulers, register files, ALUs, and L1 data caches) inside one module. Only the instruction fetch/decode front-end, the FPU, and the L2 cache were shared. So the FX design would be an in-between a 4-core + SMT and a true 8-core.
Fair, I had not delved into the details, but still they were not full cores and the marketing did not make a real distinction.
I had a pilledriver one, it was a perfectly good cpu, I would buy it again. If I remember back then it was the best overall performance per dollar, the alternatives if I remember correctly were i7-39.. and i7-38.. and were at best 50% more expensive for 10-15% more performance.
Depends what you were doing with it. The Piledriver only beat the Intels in heavily multi threaded (preferably integer) workloads like media encoding, which is why it was popular with media creator workstations on a budget, but for most consumer real world tasks at the time, like video games, Intel was way ahead in performance even though it was more expensive.
The Piledriver would win the consumer bang/buck mindset back then because of the 6-core part was reasonably priced and unlocked for overclocking, so people would overclock them to beat the more expensive (locked?) 4-c/8-t Intels at a lower price, but that ignored the costs of massive extra power draw(100+ W) over the Intel, the need for beefier more expensive coolers and power supplies, more expensive AMD motherboards with beefier MOSFET power delivery stages built to withstand the higher power draws of the Piledriver, so in the end the actual bang/buck gain of the AMD system wasn't remotely as big as people were making it out to be, they were just happy to get a "6-core" AMD cheaper than a 4-core Intel thinking more cores = more "better", same how having more mega-herz was also more "better" a decade before that.
The Team AMD VS Team Intel wars on forums on these topics were wild back then.
> (preferably integer) workloads like media encoding
Media encoding is actually an FPU workload, and a pretty brutal one at that.
Media encoding might not use much floating point arithmetic, but it does use massive amounts of packed integer SIMD. And all SIMD instructions (both integer and floating) execute on the shared FPU, not the integer unit. It's only scalar integer instructions that execute on the integer unit.
Which leads me to believe that Bulldozer's shared FPU is not a bottleneck at all. Most evidence seems to point to the shared frontend being the primary bottleneck (which is why steamroller puts some effort into duplicating the instruction decoding, for some pretty large IPC wins)
No. it's just the opposite of Hyper-thereading.
SMT it's about maximize the resource usage of a CPU, running 2 or more threads at the same time.
AMD used the opposite technique of SMT. It had a technical name that I can't remember now, and wasn't invented by AMD.
>Instead of discrete, fully independent cores, AMD grouped processing units into "Modules" where each module contained two integer execution units, but they had to share critical resources like one FPU, the instruction fetch/decode pipeline, and the L2 cache so when both "cores" inside a module were heavily taxed especially with math or physics-heavy calculations (like in videogames), they choked fighting over shared hardware.
They did just fine in parallel workloads, so I think this is not accurate. The design scaled just fine. The problem was that each core was weak.
>They did just fine in parallel workloads, so I think this is not accurate
Depends how you define "doing just fine in parallel workloads". The contemporary competition from Intel that was 4-core + SMT was beating AMD's 8-core FX CPUs in most real-world tasks and benchmarks at the time. The 8-core AMD broke even and rarely won only in >4-thread strictly integer benchmarks and some >4-thread media encoding tasks/benchmarks. So if you wanted a prosumer media encoding workstation a budget then yeah, the AMD was better, but for most real world task, it really wasn't.
>The design scaled just fine. The problem was that each core was weak.
Can you elaborate and be more exact? What you wrote is technically vague and doesn't mean anything in technical dissection/terms.
When we say a design "scales", that means that increasing the size of the workload does not incur a lot of overhead. If contention between shared resources meant that the design was not able to achieve an ~8x speedup when run with eight parallel threads, that would mean the design was not scalable. But we did in fact see a roughly 8x speedup with eight threads, so the design scaled just fine. The problem with the design was that each core was individually crummy, so even eight cores running in parallel had lackluster performance.
The myth that each two-core module functioned more like one core with hyperthreading would suggest that these CPUs would have much higher per-core performance when lightly loaded than when fully loaded. That is not what happened. Each core was crummy even when lightly loaded, but under full load you would have eight crummy cores, which would beat four Intel cores on a lot of workloads.
The only time contention was a serious problem was with workloads that were dominated by floating point, which were relatively rare.
> If contention between shared resources meant that the design was not able to achieve an ~8x speedup when run with eight parallel threads, that would mean the design was not scalable.
By that definition it definitely was not scalable.
>But we did in fact see a roughly 8x speedup with eight threads,
Care to share a source? Because AFAIR there definitely was no 8x linear speedup with 8 threads even in benchmarks, let alone in real world use cases. The only benchmarks where those 8 threads would scale best and beat Intel were archival compression/decompression and media encoding. At everything else Intel wiped the floor with it.
>The only time contention was a serious problem was with workloads that were dominated by floating point, which were relatively rare.
Many real-world compute workloads, especially gaming related, are floating point.
>Instead of discrete, fully independent cores, AMD grouped processing units into "Modules"…
This argument has never made very much sense to me. Yes, the decision to group cores into modules with some shared resources did introduce a bottleneck and result in lower performance than having isolated cores. But this didn't make the processor worse than if it didn't have the additional cores at all. These processors were at their best on highly parallel workloads. AMD shipped far more cores than Intel at the same price. The contention for the shared front end was not serious enough to make up for the core count advantage. How is the module architecture an explanation for why the design failed, when the bottleneck only becomes relevant in situations where the design is winning?
It's hard to find benchmarks from 15 years ago. But Phoronix finds what I describe: the design doesn't scale quite as well as a "true" eight-core design, but still scales better than the competition of the time which had lower core counts. Though it does seem straightforwardly bad at some workloads.
It's as FlowingRiver said. If we were to release the same parts again with modern software, Bulldozer would be a far stronger competitor to Sandy Bridge. FX aged better than Intel's designs of the same era. But Intel's designs were better to start with, so I'd still take the Core.
The reason they sucked is that they ran hot and their per-core performance was terrible.
I did run a multithreaded CPU only n-body problem resolvers in FX cores. So heavy double precision work and putting each core to 100% .
A Fx-8370E would get a speed up around 7.5 times Vs the single threaded version
A FX-4300 would get a speed up around 3.9 times Vs the single threaded version
So in a physical heavy computation task, involving double precision math (where the AMD design of share FPU units should penalize most), the FX cores where happy churning numbers with the expected speedup Vs a single core/thread version of the code. So stop saying that FX cores sucks at multithread. They fucking worked fine on that kind of tasks.
Yokolos · · focus · HN ↗
FlowingRiver · · focus · HN ↗
PorciiVorbesc · · focus · HN ↗
That's pretty much irrelevant since the AMD's FX arch's issues weren't that SW at the time wasn't using all the 8 cores. Intel dropped the Core 2 Duo and Quad into the era where most SW was still stuck in single threaded for a long time and those CPUs still ripped single-threaded SW tasks regardless.
Here's the big reasons why the FX sucked back then and why they still suck today in the multi-thread SW era:
So unless you're into collecting vintage CPUs as display pieces, this one definitely belongs in the e-waste pile instead of burning electricity, because it did not age like wine with the adoption of SW multi threading like people were hoping.MrDOS · · focus · HN ↗
It blows my mind that AMD watched Intel try to do basically the same thing only a few years prior with NetBurst, and fail so badly that they had to scrap that entire evolutionary branch and start over – and AMD still went and did it again themselves anyway.
to11mtm · · focus · HN ↗
mort96 · · focus · HN ↗
PorciiVorbesc · · focus · HN ↗
That's hugely debatable and depends on SW workloads and the SMT implementation + CPU pipeline design.
In SMT the execution engines, ALUs, FPUs, and caches are completely shared. When one thread stalls waiting for RAM, the second thread sneaks into the idle execution units. At best, SMT yields a ~10% to 20% throughput boost over a single thread.
>Because that description makes the 8 core Bulldozers sound exactly like a 4 core with SMT.
It's not the same thing. Bulldozer arch sits between a true 8-core and 4-core + SMT implementation.
mort96 · · focus · HN ↗
Exactly, which is a significant benefit for how marginal the costs are.
> It's not the same thing. Bulldozer arch sits between a true 8-core and 4-core + SMT implementation.
Then surely it should be even better than 4 cores with SMT?
If you're going to argue that the problem with Bulldozer was it's weird semi-SMT solution, you need to explain how it would've been better without it (aka as a regular quad core). Because even if it just gets the 10-20% performance improvements from being a form of SMT it would be better to have it than to not. And if you have lots of integer unit-bound threads, it should be even better than that.
PorciiVorbesc · · focus · HN ↗
I explained all the bottlenecks of the architecture in a comment above, that the issue was more than 4-core +SMT instead of true 8 cores. Please read it.
mort96 · · focus · HN ↗
Now the very long pipeline and high memory latency are obviously significant issues with the architecture but those seem disconnected from the 4-core+SMT issue? I'm not questioning those issues at all, it's just not the part of your comment which interested me
EDIT: okay so in this comment: <a href="https://news.ycombinator.com/item?id=49809017">https://news.ycombinator.com/item?id=49809017, you explain that there's actually a fairly large part of a core that's duplicated, not just two integer units. If each "core" gets its own integer unit, register file and L1 cache, you're actually paying a ton of die space for it, unlike SMT which is "free". I can totally get how that can be a terrible trade-off for most workloads if it all ends up mostly starved due to front-end/FPU/memory throughput.
to11mtm · · focus · HN ↗
AFAIR, a bulldozer 'module' has what is exposed to a core as two CPUs, but, per everything above, is two integer cores, one shared FPU core, and depending on the version of the arch, possibly shared fetch/decode/other resources between all of that. Also AFAIR the decoder sucked as far as being able to feed both the integer cores, and the integer cores were more anemic compared to what was in, say, a K10H Phenom.
mort96 · · focus · HN ↗
PorciiVorbesc · · focus · HN ↗
Having the same count of units (4 FPUs on the chip) did not mean having the same throughput. It's a HW bottleneck, not something AMD could fix via the OS's kernel allocation and scheduling of resources to the CPU to be able match Intel.
In strictly integer 4-8 thread benchmarks, yeah, AMD was often tied to Intel's 4C+SMT.
Bulldozer’s design didn't lose because the concept of sharing an FPU between two threads is worse than SMT. It lost because:
mort96 · · focus · HN ↗
This is exactly the kind of thing I've seen ChatGPT do way too much FWIW, arguments silently change after push-back without acknowledgement. I think you're either a bot, or (more embarrassingly) using ChatGPT to formulate your arguments.
wmf · · focus · HN ↗
to11mtm · · focus · HN ↗
AMD was also having to deal with the fact GloFo split off and was relying more on general 'bulk' lithography, which kneecapped them for some time especially due to yield issues on the FX series and overall cost of that deal.
Intel also very quickly after, released Sandy Bridge and aggressively scaled it up and down; the 2500K was so cheap yet powerful I know of at least one setup that ran for a decade an only got replaced because they needed to upgrade to windows 11 for compliance-esque reasons. My own 2500K I replaced in 2017-2018-ish, only because either the motherboard took an unfortunate dive and it was easier to replace both at once.
FWIW, I did do a cheapie FX build in 2015ish for my then-girlfriend as a DVR and light gaming/emulation 'under the TV box', and it did the job well for the price, but it definitely wasn't anything amazing.
It was a tough time for AMD for sure. I think the 'split' between the Cat cores (Bobcat/Jaguar) also hurt them from a resource standpoint, although one could argue that it also kept them alive to recover (i.e. Jaguar in XBox One and PS4 being a volume contract part) [0]. They did a lot of moves that caused short term pain (that glofo spinnoff helped pay off the ATI Acquisition AFAIR) but helped them become the company that is still surviving today.
[0] - One odd side note, I still find it odd that they never did a dual channel Jaguar laptop part. I still ask whether it was because it would have made the FX look that bad...
throwawayffffas · · focus · HN ↗
Yeah that's hyper-threading intel was doing it as well and all modern CPUs do it as well. Where AMD dropped the ball, was they did not disclose that in their marketing as clearly as they should.
All CPUs today are marketed as x cores 2x threads, back then some AMD marketing genius in their infinite wisdom put 8 cores on the box, instead of the honest 4 cores with hyperthreading.
PorciiVorbesc · · focus · HN ↗
throwawayffffas · · focus · HN ↗
I had a pilledriver one, it was a perfectly good cpu, I would buy it again. If I remember back then it was the best overall performance per dollar, the alternatives if I remember correctly were i7-39.. and i7-38.. and were at best 50% more expensive for 10-15% more performance.
PorciiVorbesc · · focus · HN ↗
The Piledriver would win the consumer bang/buck mindset back then because of the 6-core part was reasonably priced and unlocked for overclocking, so people would overclock them to beat the more expensive (locked?) 4-c/8-t Intels at a lower price, but that ignored the costs of massive extra power draw(100+ W) over the Intel, the need for beefier more expensive coolers and power supplies, more expensive AMD motherboards with beefier MOSFET power delivery stages built to withstand the higher power draws of the Piledriver, so in the end the actual bang/buck gain of the AMD system wasn't remotely as big as people were making it out to be, they were just happy to get a "6-core" AMD cheaper than a 4-core Intel thinking more cores = more "better", same how having more mega-herz was also more "better" a decade before that.
The Team AMD VS Team Intel wars on forums on these topics were wild back then.
phire · · focus · HN ↗
Media encoding is actually an FPU workload, and a pretty brutal one at that.
Media encoding might not use much floating point arithmetic, but it does use massive amounts of packed integer SIMD. And all SIMD instructions (both integer and floating) execute on the shared FPU, not the integer unit. It's only scalar integer instructions that execute on the integer unit.
Which leads me to believe that Bulldozer's shared FPU is not a bottleneck at all. Most evidence seems to point to the shared frontend being the primary bottleneck (which is why steamroller puts some effort into duplicating the instruction decoding, for some pretty large IPC wins)
Zardoz84 · · focus · HN ↗
adfghopmnoi · · focus · HN ↗
They did just fine in parallel workloads, so I think this is not accurate. The design scaled just fine. The problem was that each core was weak.
PorciiVorbesc · · focus · HN ↗
Depends how you define "doing just fine in parallel workloads". The contemporary competition from Intel that was 4-core + SMT was beating AMD's 8-core FX CPUs in most real-world tasks and benchmarks at the time. The 8-core AMD broke even and rarely won only in >4-thread strictly integer benchmarks and some >4-thread media encoding tasks/benchmarks. So if you wanted a prosumer media encoding workstation a budget then yeah, the AMD was better, but for most real world task, it really wasn't.
>The design scaled just fine. The problem was that each core was weak.
Can you elaborate and be more exact? What you wrote is technically vague and doesn't mean anything in technical dissection/terms.
adfghopmnoi · · focus · HN ↗
The myth that each two-core module functioned more like one core with hyperthreading would suggest that these CPUs would have much higher per-core performance when lightly loaded than when fully loaded. That is not what happened. Each core was crummy even when lightly loaded, but under full load you would have eight crummy cores, which would beat four Intel cores on a lot of workloads.
The only time contention was a serious problem was with workloads that were dominated by floating point, which were relatively rare.
PorciiVorbesc · · focus · HN ↗
By that definition it definitely was not scalable.
>But we did in fact see a roughly 8x speedup with eight threads,
Care to share a source? Because AFAIR there definitely was no 8x linear speedup with 8 threads even in benchmarks, let alone in real world use cases. The only benchmarks where those 8 threads would scale best and beat Intel were archival compression/decompression and media encoding. At everything else Intel wiped the floor with it.
>The only time contention was a serious problem was with workloads that were dominated by floating point, which were relatively rare.
Many real-world compute workloads, especially gaming related, are floating point.
c4rnifex · · focus · HN ↗
This argument has never made very much sense to me. Yes, the decision to group cores into modules with some shared resources did introduce a bottleneck and result in lower performance than having isolated cores. But this didn't make the processor worse than if it didn't have the additional cores at all. These processors were at their best on highly parallel workloads. AMD shipped far more cores than Intel at the same price. The contention for the shared front end was not serious enough to make up for the core count advantage. How is the module architecture an explanation for why the design failed, when the bottleneck only becomes relevant in situations where the design is winning?
It's hard to find benchmarks from 15 years ago. But Phoronix finds what I describe: the design doesn't scale quite as well as a "true" eight-core design, but still scales better than the competition of the time which had lower core counts. Though it does seem straightforwardly bad at some workloads.
<a href="https://www.phoronix.com/review/amd_bulldozer_scaling/7" rel="nofollow">https://www.phoronix.com/review/amd_bulldozer_scaling/7
It's as FlowingRiver said. If we were to release the same parts again with modern software, Bulldozer would be a far stronger competitor to Sandy Bridge. FX aged better than Intel's designs of the same era. But Intel's designs were better to start with, so I'd still take the Core.
The reason they sucked is that they ran hot and their per-core performance was terrible.
Zardoz84 · · focus · HN ↗
So in a physical heavy computation task, involving double precision math (where the AMD design of share FPU units should penalize most), the FX cores where happy churning numbers with the expected speedup Vs a single core/thread version of the code. So stop saying that FX cores sucks at multithread. They fucking worked fine on that kind of tasks.