diff options
author | Bastien Montagne <b.mont29@gmail.com> | 2019-11-26 16:26:47 +0300 |
---|---|---|
committer | Bastien Montagne <b.mont29@gmail.com> | 2019-11-26 16:30:41 +0300 |
commit | fcbec6e97e649eee33f06e0202455ee11dcfe46e (patch) | |
tree | 05b21434a9a5974be893326ad378f69d4d3521b4 /release/scripts/modules | |
parent | 9ecc30250aaea4e102e869f181e4c896c315e5ef (diff) |
BLI_task: Add pooled threaded index range iterator, Take II.
This code allows to push a set of different operations all based on
iterations over a range of indices, and then process them all at once
over multiple threads.
This commit also adds unit tests for both old un-pooled, and new pooled
task_parallel_range family of functions, as well as some basic
performances tests.
This is mainly interesting for relatively low amount of individual
tasks, as expected.
E.g. performance tests on a 32 threads machine, for a set of 10
different tasks, shows following improvements when using pooled version
instead of ten sequential calls to BLI_task_parallel_range():
| Num Items | Sequential | Pooled | Speed-up |
| --------- | ---------- | ------- | -------- |
| 10K | 365 us | 138 us | 2.5 x |
| 100K | 877 us | 530 us | 1.66 x |
| 1000K | 5521 us | 4625 us | 1.25 x |
Differential Revision: https://developer.blender.org/D6189
Note: Compared to previous commit yesterday, this reworks atomic handling in
parallel iter code, and fixes a dummy double-free bug.
Now we should only use the two critical values for synchronization from
atomic calls results, which is the proper way to do things.
Reading a value after an atomic operation does not guarantee you will
get the latest value in all cases (especially on Windows release builds
it seems).
Diffstat (limited to 'release/scripts/modules')
0 files changed, 0 insertions, 0 deletions