# More Threading issue

**URL:** https://discourse.itk.org/t/more-threading-issue/438
**Category:** Engineering
**Created:** [November 20, 2017, 9:06pm UTC](https://discourse.itk.org/t/more-threading-issue/438 "2017-11-20T21:06:23Z")
**Posts on this page:** 8
**Page:** 1

<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: [November 20, 2017, 9:06pm UTC](https://discourse.itk.org/t/more-threading-issue/438/1 "2017-11-20T21:06:23Z")

</div>

The server I am working on has 2 socket with 44 physical cores configured to run with hyper-threading. My general experience with hyper-threading is: It does not hurt the through put, and some times the feature does improve the performance. So I am running with what ITK should default to as 88 threads.

On the master branch, I noticed that the test `SliceImageFilterTests.PhysicalPoint1` was running particularly slow.

The test takes 270 seconds when `ctest -V -R SliceImageFilterTests.PhysicalPoint1`, but taking just 6.4 seconds when `ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=88 ctest -V -R SliceImageFilterTests.PhysicalPoint1` is run.

Similarly, when running the whole test suit it took 305 seconds with running just `ctest -j 80`, while just 142 seconds with `ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=88 ctest -j 80`. It’s my expectation that these should both be running filters with a 88 threads by default.

Something funny is happening…  
@dzenanz

---

<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: [November 20, 2017, 10:11pm UTC](https://discourse.itk.org/t/more-threading-issue/438/2 "2017-11-20T22:11:24Z")

</div>

I don’t know why 88 wouldn’t be the default number of threads. On my computer, `ctest -C RelWithDebInfo -V -R SliceImageFilterTests.PhysicalPoint1` runs in about 2.5 seconds. And it is being run with 4 threads, as expected.

Can you trace `ThreadPool::GetGlobalDefaultNumberOfThreads()` in \Modules\Core\Common\src\itkThreadPool.cxx? The `threadCount` variable should be 88. If it is not, please explain what is causing that behavior.

---

<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: [November 21, 2017, 3:03pm UTC](https://discourse.itk.org/t/more-threading-issue/438/3 "2017-11-21T15:03:31Z")

</div>

So looking at the code closer it looks like the TheadPool is always created:

> <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkMultiThreader.cxx#L170>

and the thread pool always create all the thread in the constructor:

> <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkThreadPool.cxx#L67>

This seems potentially problematic to me…

---

<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: [November 21, 2017, 3:19pm UTC](https://discourse.itk.org/t/more-threading-issue/438/4 "2017-11-21T15:19:58Z")

</div>

Should I make it create threads the first time `AddWork` is invoked? Or create “up to N” threads as needed in `AddWork` (N=GlobalDefaultNumberOfThreads)?

---

<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: [November 21, 2017, 3:38pm UTC](https://discourse.itk.org/t/more-threading-issue/438/5 "2017-11-21T15:38:25Z")

</div>

For the default case when the thread pool is not being used it should not be created.

Consider wrapping the MultiTheader’s usage of the m\_ThreadPool with a getter method. Then the thread pool does not have to be constructed in the MultiThread’s constructor, it can be constructor in the getter if and when it’s needed.

I hacked not constructing the ThreadPool, and it did not solve my reported problem.

---

<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: [November 21, 2017, 5:22pm UTC](https://discourse.itk.org/t/more-threading-issue/438/6 "2017-11-21T17:22:22Z")

</div>

Here is a patch which addresses the specific issue I encountered:  
[http://review.source.kitware.com/#/c/22813/](http://review.source.kitware.com/#/c/22813/)

The motivations for the modification to the GlobalDefaultNumberOfThreads is not clear to me. Specifically, I don’t know when the one method was moved to the TheadPool from the multi-threader.

---

<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: [November 21, 2017, 5:44pm UTC](https://discourse.itk.org/t/more-threading-issue/438/7 "2017-11-21T17:44:02Z")

</div>

I moved it during the big thread pool [rewrite](https://github.com/InsightSoftwareConsortium/ITK/commit/f2b6450bacb2d720149ad8271181959f4755b180). The move was done to avoid circular dependency. Without moving that method to thread pool, ThreadPool would also depend on MultiThreader.

---

<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: [November 21, 2017, 6:31pm UTC](https://discourse.itk.org/t/more-threading-issue/438/8 "2017-11-21T18:31:23Z")

</div>

Yes. The separation between the two classes is not very clean right now.