How C++23 made my Thread Pool twice as fast

Рет қаралды 3,046

Күн бұрын

Пікірлер: 14

@ScaryHutmanPictures 2 ай бұрын

2:52 possibly undefined behaviour/bug. You are calling queue.front() which returns a reference to the first element. Then you .pop() the first element and your func reference may become invalid.

@MaitreBart Жыл бұрын

I don't understand why you need to do move(task)() when inside the {} of the wraper_func lambda? Why not just task()?

@ZenSepiol Жыл бұрын

Just an oversight. I guess it’s not needed.

@jhummelgaard9310 4 ай бұрын

Thank you!!

@tigrux Жыл бұрын

🤯

@redhawk3385 Жыл бұрын

love the content, it would be amazing to see your reactions/takes to how rust is designed. Rust takes after c++ with raii and zero-cost abstractions.

@ZenSepiol Жыл бұрын

Rust is amazing. I have already worked with it. My guess is, it will steadily increase its share the next few years. Only issue is the existing large legacy codebases that will slow the transition down.

@niklkelbon3662 7 ай бұрын

This maybe slowest possible thread pool ever

@n00blamer 7 ай бұрын

TL;DR - I'd look at the queue first, there should be 10-100x more action per second. Probably a mutex in there, not something wait- or lock free.

@n00blamer 7 ай бұрын

The real problems begin when you have 30-40 threads; when microbenchmarking they hit the queue too frequently and synchronizing the cache is beginning to be issue. Having N internal queues is also problematic since work stealing or any sort of work balancing will mean communication between threads (=cores) which is memory writing and root cause for the issues. TP + lots of cores + microbenchmarking = bad experience, but in the video's case 3 ms for 1000 tasks is at least 10-30x less than what it should be, that's why the queue is the suspect number one. If this is for "real" work it's roughly 350K tasks per second, if you use this for a game that could potentially run 120 fps that's still 2900 tasks per frame or so, but taking all CPU for one core for the orchestration which is unacceptable. Let's say 10% so ~ 300 tasks per frame, that should get a lot done but it's possible to bump that to 3000-20,000 tasks per frame if needed with some re-structuring of the code but even 1000 tasks sounds stupid amount and wasteful. IDK, it gets a bit muddy here what the use case is going to be but the current code should do alright as it is.

@ZenSepiol 7 ай бұрын

Did you measure? I just ran this on a (very limited) virtual machine, so obviously my numbers are quite low. The code itself should perform decently, but is not optimized for any specific usecase. The best thread pool implementation is heavily depending on the task itself, there are lots of options to optimize with different pros and cons.