- Supports limiting concurrency essentially giving the option of carving smaller threadpools out of a bigger one
- Supports priority mapping function to allow per instance priority scheduling
- In Editor, GThreadPool is now carved up from GLargeThreadPool by wrapping it and limiting concurrency
- Can also reduce latency on the main thread pool because work items are scheduled just-in-time giving
the chance to other wrapped queues to take turn and each make progress even if they have hundreds
of tasks in their respective queue.
#rb Andriy.Tylychko, Francis.Hurteau
[CL 13682779 by danny couture in ue5-main branch]
- This allows to use the GLargeThreadPool and benefit from all available cores even for low priority tasks.
- Using this implementation, DistanceFields computations, Async resources building, AssetRegistry scanning could all run from the same pool at max cores efficiency.
- Add synthetic micro-benchmark to isolate new implementation performance and compare it against the old one.
BenchmarkTool.exe -Benchmark=BM_ThreadPoolOverhead
Best 3 out of 10 runs
Before BM_ThreadPoolOverhead 100000 iterations took 946 ms (9.465282 us/iteration)
BM_ThreadPoolOverhead 100000 iterations took 947 ms (9.473544 us/iteration)
BM_ThreadPoolOverhead 100000 iterations took 948 ms (9.485538 us/iteration)
After BM_ThreadPoolOverhead 100000 iterations took 944 ms (9.441136 us/iteration)
BM_ThreadPoolOverhead 100000 iterations took 940 ms (9.407212 us/iteration)
BM_ThreadPoolOverhead 100000 iterations took 941 ms (9.410743 us/iteration)
#rb Andriy.Tylychko
[CL 13607892 by danny couture in ue5-main branch]
