Re:A Universal I/O Abstraction for C++ (2020)
by jcelerier on Monday April 19, 2021 @03:01AM
(#26859824)
> In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff.
well, yes, those are things that happen fairly often. e.g. there's a lot of work on optimizing code for various arm big.LITTLE things, where you have some algorithm that you want to make sure runs on the "big" cores.
Re:A Universal I/O Abstraction for C++ (2020)
by Const-me on Monday April 19, 2021 @03:09AM
(#26859861)
Can’t you use two shared thread pools, with threads affinity set to the big and little parts of the CPU, respectively?
I think for most use cases runtime scheduling is better than compile-time one. Because other processes sharing the hardware, and because tasks take unpredictable time, depends on almost everything including ambient temperature. Not to mention compilers don’t generally know count of cores, outside of a few niches like embedded, iOS and consoles games.
Why it would make sense?
In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff. Generally, throwing tasks into a shared thread pool is the way to go.