No progress reporting in ITK5

Engineering
21

What are the advantages/disadvantages of pool versus platform?

I can’t guarantee that TBB will be available (I think), and I’ve adopted the convention of making the number of threads a command line argument so users can specify the max number easily for Sun Grid Engine jobs, where the number of CPU “slots” can be requested so you want to match the number of threads to the number of slots. I’ve been setting the number of work units with this->GetMultiThreader()->SetNumberOfWorkUnits(this->GetNumberOfWorkUnits()); in GenerateData, which seemed to give me the (N - 1) behaviour?

22

Number of work units is, by default, a few times greater than number of threads. This allows load balancing. If correct progress reporting is more important to you than load balancing you should set it to be equal to the number of threads.

23

Oh, the more important problem is that the first work unit happens to be much smaller, so even with WU=threads you still only get to 38%. You need to use TBB or we need to fix pool multi-threader.

24

That would be my inclinations. This would also ensure there are always N thread running, with out the bonus thread in the beginning.

This is not what I expected. Does the filter make it to 100% with 1 thread?

25

Yes, it does make it to 100% with 1 thread, however, it prints:

08:48:22 Progress: 98% complete
08:48:22 Progress: 99% complete
08:48:22 Progress: 100% complete
08:48:22 Progress: 0% complete

at the end.

With 2 threads, it gets to 70%, 3 threads 50 %, 4 threads 45%, 5 threads 48% (!?!), 6 threads 38%.

I should have noted this is with 5.1rc03, not master, on MacOS. Any other info I can provide?

26

I am moving towards distributing my tools as a single binary with static linking (including statically linking libstdc++ or equivalent), in order to make it easier for academic collaborators to use them. I think this is incompatible with TBB?

(Also at some point I really want to get an AMD ThreadRipper!)

27

TBB works well with AMD processors. My main computer in the office has a Ryzen, and I was able to use TBB and MKL without issues.

1 Like
28

Brad, do you want to take a stab at fixing pool multi threader’s progress reporting, or do you want to let me do it? I will probably get to it next week. But we should definitely do it before 5.1 final.

29

I think this is more a a fix to the ThreadPool, so that falls into your court. Once the main thread participates and there a just N threads with out the bonus, then I can follow up as needed.

Looking into to this a bit further, it’s seems more complicated. The ThreadPool is a singleton object, which may have work items from multiple “jobs” ( e.g. multiple filter running concurrently ).

30

So this filter’s main thread might execute another filter’s work unit. No big deal. We could increment progress by 0 after each work unit is executed, to make sure the main thread reports progress at least occasionally.

31

Easier linking is just a tiny step in making your software a bit more accessible. If you want your work to make impact (not just picked up by your direct collaborators but discovered by many researchers and clinicians around the world), then you need to ensure that your users can try your tools with a few minutes of work, with a convenient and intuitive graphical user interface.

Developing a GUI and maintaining and distributing an application requires a completely different skillset than developing algorithmic tools and it is a lot of effort. Fortunately, this effort can be shared between many projects. That’s why 3D Slicer has been developed and it is a huge success, with 160+ extensions contributed by hundreds of developers around the world and over 15k new downloads each month. We have ITK, VTK, Qt (built with TBB, thoroughly tested and optimized on all desktop platforms), and it includes a full Python environment, which allows you to install and use any Python packages. All basic features (data import/export, visualization, quantification, segmentation, registration, etc.) are already provided by the platform, so all you have to do is to implement a small GUI for your tool, either in Python or in C++ (or if you have a command-line tool then you can just create an XML file that describes input and output arguments for your tool and Slicer generates a GUI automatically), and submit your repository to the Slicer extensions index.

We would love to see your tools as a 3D Slicer extension. Let us know at discourse.slicer.org if we can help with anything to make it happen.

1 Like
32

It could be… A quick filter’s main thread could pick up a long job, and mess up assumptions of an application. There could be some other complicated cases with regard to the special main/envoking thread and events.

33

Then we should use wait_for instead of get for the std::future returned by thread pool. And every 1-10 milliseconds do a dummy progress increment. Less code and should work well. What do you think @blowekamp?

1 Like
34

Yes. The main thread could not participate in the processing, and just loops checking on the jobs and reporting progress. I see less potential consequences for this approach.

35

@lassoan Thanks for the kind words. I have no objections to my tools ending up in Slicer, but I don’t have the bandwidth to work on that. Sadly such niceties do not result in further funding for my position (such is post-doc life).

@dzenanz Please ping me when you make any progress and I will gladly test.

1 Like
36

It is my understanding that 5.1 will be tagged in the next couple days. So the correction to such a core component should not be made at the last minute.

I have time this morning to take a stab at this fix, with your proposed solution.

37

Go for it.

We don’t have to integrate it before 5.1, but the option would be nice.

38

I implemented this in PR 1914. @spinicist can you try it?

1 Like