It seems official python wheels were built without parallelization (openmp or tbb) support even if a handful of filters had vtkSMPTools support.
I would think stdThread would be the best back-end to use as it does not requires external dependency.
There are still some issues to set this backend as default VTK wide, wich would ends up in the python wheel as weel. I will try to update the current status. The result of this pipeline will be used to update the main issue.
Openmp also seems to be feasible cause almost all modern c++ compilers already have built-in support.
Not on windows, no.
Charles I agree std::thread is probably the best backend in terms of eliminating dependencies etc. However, I have found cases where it is much, much slower than TBB (e.g. 2X) since it appears that its load balancing is poor. std::thread also seems to be very brittle. Ideally it would be nice to put VTK’s best foot forward if at all possible.
Part of these performance issue are to be addressed soon in the following MR. Once merged, I plan to update the status of the stdThread back-end. First ensuring all tests are green, then to check the perf.
For now on, even with the mentioned MR, the work stealing will be less advanced than the TBB one, leading to possible imbalance, but we have some tricks to try.
Most excellent, I’m looking forward to seeing how this turns out