←back to thread

151 points ibobev | 1 comments | | HN request time: 0.001s | source
Show context
jandrewrogers ◴[] No.45660889[source]
I've worked on several thread-per-core systems that were purpose-built for extreme dynamic data and load skew. They work beautifully at very high scales on the largest hardware. The mechanics of how you design thread-per-core systems that provide uniform distribution of load without work-stealing or high-touch thread coordination have idiomatic architectures at this point. People have been putting thread-per-core architectures in production for 15+ years now and the designs have evolved dramatically.

The architectures from circa 2010 were a bit rough. While the article has some validity for architectures from 10+ years ago, the state-of-the-art for thread-per-core today looks nothing like those architectures and largely doesn't have the issues raised.

News of thread-per-core's demise has been greatly exaggerated. The benefits have measurably increased in practice as the hardware has evolved, especially for ultra-scale data infrastructure.

replies(3): >>45661411 #>>45661630 #>>45667563 #
1. torginus ◴[] No.45667563[source]
If I remember correctly, these work stealing task schedulers started getting pushed around the mid 2000s as a result of Intel failing to scale the Pentium 4 architecture to expected single-thread performance levels.

Libraries like .NET's Task Parallel Library or Intel Threaded Building Blocks pretty much cemented these work-stealing task architectures. It's not that they didn't work well enough, but Intel Core came along, and single-threaded perf scaling was possible again, so these libraries became less of a focus.

It seems multi-core interest is back.