5 ms·
Thread-per-core has been around for a while! It's how a lot of modern multicore languages work. You've probably heard of "green" or "lightweight" threads before
by shwestrick 6y ago
Thread-per-core has been around for a while! It's how a lot of modern multicore languages work. You've probably heard of "green" or "lightweight" threads before... it's all the same idea. Typically, you'd want to use a scheduler (probably work-stealing https://en.wikipedia.org/wiki/Work_stealing https://en.wikipedia.org/wiki/Work_stealing) under the hood to dynamically assign tasks to processors, which is much more effective at load-balancing than "sharding".
All of these languages/libraries use a dynamic scheduler for load-balancing:
* Rayon (Rust) [https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon]
* Goroutines (Go) [https://golangbyexample.com/goroutines-golang/ https://golangbyexample.com/goroutines-golang/]
* OpenMP [https://www.openmp.org/ https://www.openmp.org/]
* Task Parallel Library (.NET) [https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/task-parallel-library-tpl https://docs.microsoft.com/en-us/dotnet/standard/parallel-pr...]
* Thread Building Blocks (C++) [https://software.intel.com/content/www/us/en/develop/tools/threading-building-blocks.html https://software.intel.com/content/www/us/en/develop/tools/t...]
* Cilk (C/C++) [http://cilk.mit.edu/ http://cilk.mit.edu/]
* Java Fork-Join and Parallel Streams [https://docs.oracle.com/javase/tutorial/collections/streams/parallelism.html https://docs.oracle.com/javase/tutorial/collections/streams/...]
* ParlayLib (C++) [https://github.com/cmuparlay/parlaylib https://github.com/cmuparlay/parlaylib]
- imtringued 6y agoIf it's not partitioning data per processing unit then it would not be considered a "thread-per-core" architecture based on the definition the article provided. Work stealing means more than one thread can be responsible for a single piece of data. This could result in crossing NUMA nodes or servers.
- shwestrick 6y agoHmm I was separating the concept of "thread-per-core" from sharding. I would argue that typical cooperative task schedulers (e.g. work-stealing) get the performance benefits of thread-per-core without requiring any static partitioning. But if thread-per-core is fundamentally tied to the idea of sharding, then I think I see what you're saying.