3 ms·
This approach is extremely popular. С++ have it with parallel-for like libraries. It has some downsides. When multiple threads join before allowing to continue
by SleepyMyroslav 3y ago
This approach is extremely popular. С++ have it with parallel-for like libraries.
It has some downsides. When multiple threads join before allowing to continue it leaves some perf on the table. If you have limited number of threads to hardware concurrency then any thread that reaches join point is typically unavailable to deal with remaining work or other algorithms.
In gamedev with limited concurrency due to hardware it is more beneficial to let every worker thread to participate all the time. Instead of joining back to sequential execution one uses task dependencies. If continuation is done as separate task that is scheduled "when all" of the dependencies are done then there are no threads that unavailable due to waiting. This way if you have multiple parallel algorithms in flight then every thread is available for any task. Instead of me handwaving it here it is probably better to check a presentation from Sean Parent [1]
1. https://sean-parent.stlab.cc/papers-and-presentations/#better-code-concurrency https://sean-parent.stlab.cc/papers-and-presentations/#bette...