Comment by mort96 | Hacker News Reader

Comment by mort96 | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com