undefined

points

[-]

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

by mort9656 minutes ago|

parent|

[-]

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.

by to11mtm45 minutes ago|

parent|

[-]

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.

by mort9640 minutes ago|

parent|

[-]

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.

by PorciiVorbesc44 minutes ago|

parent|

prev|

[-]

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.