Re:Intel's make-or-break 18A process node debuts for data ce...
by Retr0id on Tuesday March 03, 2026 @03:44PM
(#47238689)
Maybe no fundamental bottlenecks but it's easy to accidentally write software that doesn't scale as linearly as it should, e.g. if there's suddenly more lock contention than you were expecting, or in a more extreme case if you have something that's O(n^2) in time or space, where n is core count.
Re:Intel's make-or-break 18A process node debuts for data ce...
by dehrmann on Tuesday March 03, 2026 @09:23PM
(#47242195)
> I don't think there are any fundamental bottlenecks here.
You memory only has so much bandwidth, but now it's shared by even more cores.
Re:Intel's make-or-break 18A process node debuts for data ce...
by lich_king on Wednesday March 04, 2026 @10:41AM
(#47249120)
You're responding out of context. The parent was asking if there are bottlenecks specifically related to scheduling. I explicitly made the point that if there are bottlenecks, they're more likely related to memory.
The bottlenecks are pretty much hardware-related - thermal, power, memory and other I/O. Because of this, you presumably never get true "288 core" performance out of this - as in, it's not going to mine Bitcoin 288 as fast as a single core. Instead, you have less context-switching overhead with 288 tasks that need to do stuff intermittently, which is how most hardware ends up being used anyway.