# No progress reporting in ITK5

**URL:** <https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630>\
**Category:** Engineering\
**Created:** [January 16, 2020, 9:38pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630 "2020-01-16T21:38:50Z")\
**Posts on this page:** 18\
**Page:** 2

<div class="post-metadata">

**Author:** ![spinicist](https://discourse.itk.org/user_avatar/discourse.itk.org/spinicist/32/183_2.png) [@spinicist](https://discourse.itk.org/u/spinicist)\
**Post date:** [April 16, 2020, 9:02pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/21 "2020-04-16T21:02:09Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 16, 2020, 9:07pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/22 "2020-04-16T21:07:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 16, 2020, 9:09pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/23 "2020-04-16T21:09:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [April 16, 2020, 9:16pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/24 "2020-04-16T21:16:31Z")

</div>

> [@dzenanz](#):
>
> We could also fix pool multi-threader. One possibility is to create and expose `ExecuteOneWorkUnit` as a public method, which would be normally used by `ThreadPool::ThreadExecute` 's loop. And when needed, also by `PoolMultiThreader::SingleMethodExecute` .

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

> [@spinicist](#):
>
> `ITK_GLOBAL_DEFAULT_THREADER=platform` gives similar output before, but gets to `Progress: 38% complete` , for both 6 & 7 threads.

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

---

<div class="post-metadata">

**Author:** ![spinicist](https://discourse.itk.org/user_avatar/discourse.itk.org/spinicist/32/183_2.png) [@spinicist](https://discourse.itk.org/u/spinicist)\
**Post date:** [April 17, 2020, 7:52am UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/25 "2020-04-17T07:52:36Z")

</div>

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

```auto
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?

---

<div class="post-metadata">

**Author:** ![spinicist](https://discourse.itk.org/user_avatar/discourse.itk.org/spinicist/32/183_2.png) [@spinicist](https://discourse.itk.org/u/spinicist)\
**Post date:** [April 17, 2020, 7:59am UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/26 "2020-04-17T07:59:31Z")

</div>

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!)

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 17, 2020, 10:57am UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/27 "2020-04-17T10:57:20Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 17, 2020, 11:49am UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/28 "2020-04-17T11:49:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [April 17, 2020, 1:45pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/29 "2020-04-17T13:45:56Z")

</div>

> [@dzenanz](#):
>
> 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.

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.

> [@blowekamp](#):
>
> > [@dzenanz](#):
> >
> > You could set number of work units to be equal to number of cores in your filter’s constructor, build ITK with TBB, or explicitly request platform multi threader (also in the filter’s constructor).
> > 
> > We could also fix pool multi-threader. One possibility is to create and expose `ExecuteOneWorkUnit` as a public method, which would be normally used by `ThreadPool::ThreadExecute` 's loop. And when needed, also by `PoolMultiThreader::SingleMethodExecute` .
> 
> That would be my inclinations. This would also ensure there are always N thread running, with out the bonus thread in the beginning.

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 ).

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 17, 2020, 1:57pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/30 "2020-04-17T13:57:37Z")

</div>

> [@blowekamp](#):
>
> multiple filter running concurrently

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.

---

<div class="post-metadata">

**Author:** ![lassoan](https://discourse.itk.org/user_avatar/discourse.itk.org/lassoan/32/27_2.png) [@lassoan](https://discourse.itk.org/u/lassoan)\
**Post date:** [April 17, 2020, 2:21pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/31 "2020-04-17T14:21:29Z")

</div>

> [@spinicist](#):
>
> 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?

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](http://discourse.slicer.org) if we can help with anything to make it happen.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [April 17, 2020, 2:23pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/32 "2020-04-17T14:23:24Z")

</div>

> [@dzenanz](#):
>
> So this filter’s main thread might execute another filter’s work unit. No big deal.

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.

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 17, 2020, 2:54pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/33 "2020-04-17T14:54:56Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [April 17, 2020, 3:28pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/34 "2020-04-17T15:28:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![spinicist](https://discourse.itk.org/user_avatar/discourse.itk.org/spinicist/32/183_2.png) [@spinicist](https://discourse.itk.org/u/spinicist)\
**Post date:** [April 20, 2020, 7:27am UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/35 "2020-04-20T07:27:13Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [April 20, 2020, 2:26pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/36 "2020-04-20T14:26:40Z")

</div>

> [@dzenanz](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [April 20, 2020, 2:50pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/37 "2020-04-20T14:50:34Z")

</div>

Go for it.

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

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [July 8, 2020, 5:08pm UTC](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630/38 "2020-07-08T17:08:06Z")

</div>

I implemented this in [PR 1914](https://github.com/InsightSoftwareConsortium/ITK/pull/1914). @spinicist can you try it?

[Previous page](https://discourse.itk.org/t/no-progress-reporting-in-itk5/2630.md?page=1)