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