Discussion on vtkSmpTools improvement

Development
#1

Greetings,

As part of an internship at Kitware, I’m going to work on improving vtk SMP tools. And we would like to engage the broader VTK community for ideas and feedback.

The main goal of this work is to support VTK-m as a new backend of the SMP tools.
Some intermediate tasks will be to integrate more utility functions (inspired by VTK-m algorithms) such as Transform and Fill in vtkSmpTools.

As a potential thing to do we could also refactor SMP tools current architecture to support multiple backends at compile and select one at runtime.
Other non-exhaustive features could be: the support of lambdas, an environment variable to control the number of threads…

We are open to any suggestions you may have.
Let me know what your thoughts are about this, and if you have any questions.

Thanks for your attention,
Timothée Couble

3 Likes
#2

I think this is a great idea and it will let developpers use VTK-m much more simply, even if not to it’s full capacity.

#3

Hi all,

There is a pending MR for changing the (maximum) number of threads at runtime, using a VTK_SMP_MAX_THREADS environment variable.

https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7794

Please let me know if you have any feedback about this changes.

1 Like
#4

Great work, customers have asked for this feature, thanks

#5

Why is this needed when the Initialize method passes the number of threads as a parameter?

#6

Because this is a control that is important to expose at high-level but modifying every single filter using vtkSMPTools with a dedicated parameter would not be practical.

1 Like
#7

Timothée,

Where I work we’ve recently looked/tried to start using TBB with VTK. We did measure performance improvements using it, but recently gave up for a few reasons, which may interest you.

  1. The newest TBB uses CMake and is thus easier to work with, but…

  2. VTK doesn’t support the newest TBB https://gitlab.kitware.com/vtk/vtk/-/issues/18107

  3. TBB doesn’t play nice with Thread Sanitizer (TSan) https://github.com/oneapi-src/oneTBB/issues/358 It’s quite valuable to us that our whole test suite passes with TSan, so introducing something that does not is disagreeable.

Given these issues, I’ve wondered about the feasibility of a GCD (Grand Central Dispatch) backend to vtkSMPTools. See: https://en.wikipedia.org/wiki/Grand_Central_Dispatch

Sean

2 Likes
#8

This is a great point. When vtkSMPTools was first introduced, it included a backend based on vtkMultiThreader. It was a “batteries included” sort of backend, since it didn’t add any extra dependencies that might block its use in certain applications. Are C++11 threads mature enough that they could be used to create a similar batteries-included backend? I’m not asking anyone at Kitware to actually do the implementation, I’m just wondering if people think it’s feasible and whether it might be accepted into the VTK codebase.

I know it wouldn’t provide the same performance as TBB or other backends, but it would be close, and there is tremendous value in having something that can be part of the default VTK build. For example, people who grab VTK from PyPi don’t get any SMP at all (except for the vtkMultiThreader stuff in the imaging pipeline). There are huge parts of the VTK community who aren’t getting any benefit from the current SMP back ends. And I say this as a member of the community, who contributes to VTK for the benefit of the community.

2 Likes
#9

I can only find one place in VTK where vtkSMPTools::Initialize() is actually called.

#10

Indeed, because Initialize is automatically called when using vtkSMPTools::For.

Edit: Looks like I was wrong, I’ll let @Charles_Gueunet and @Timothee_Couble answer here.

#11

The vtkSMPTools::Initialize() was not called before vtkSMPTools::For but after some discussion with @mwestphal and @Charles_Gueunet, we change this behavior in the above MR (7794)

1 Like
#12

So now, if a developer calls vtkSMPTools::Initialize(x) in their application, your changes are going to override/alter their specified thread count.

#13

Good point, it would be good if VTK would defer to the application if necessary. Can we add a vtkSMPTools::IsInitialized() method to check if initialization has already occurred? I suppose it depends on the backend, evidently in TBB tbb::this_task_arena::current_thread_index() function returns tbb::task_arena::not_initialized if the thread has not yet initialized the task scheduler.

#14

Yes indeed, we removed this behavior in the MR.

Multiple solution are still being discussed internally:

  • one of them would be to have the possibility to create a local instance (of vtkSMPTools or of a vtkSMPToolsLocalParameters class) that would drive the number of thread locally.
  • or we could also consider that Initialize should be called only once at the beginning of the pipeline.

The vtkSMPTools::IsInitialized would be especially useful for this second proposition.

1 Like