ITK 4.13.2, Release build
On Windows, my ITK app utilizes all 8 CPUs, however on Linux all ITK threads share a single CPU and is dog-slow. If you look at the attached screenshot you’ll see what I mean.
itk::MultiThreader::GetGlobalMaximumNumberOfThreads() = 128
itk::MultiThreader::GetGlobalDefaultNumberOfThreads() = 8
Any ideas what might cause this? Thanks.
Have you been fiddling with CPU affinity somehow? Specifically for your VisTool executable, or in general? Nothing else comes to mind which could force all the threads to run on the same core.
No, nothing like that. In fact, if you look at the thread list in the screenshot you can see that all the other threads spawned from that process do get scheduled on other CPUs, it’s just those ITK threads that all get clumped together onto CPU 1 for some reason. The same code on Windows (same hardware) runs fast, with the threads spread across all CPUs as you would expect.
Wondering if maybe there is a CMake parameter or something that I failed to set properly when building ITK that could affect this?
I don’t know any reasons why that would happen. Maybe @blowekamp, @hjmjohnson or @matt.mccormick do?
As a first step, upgrade to ITK 5, which has greatly improved threading.
The left hand column is labeled “PID” or Process ID, modern GNU/Linux’s light weight threads which ITK uses should all be under the same process. Is there anything interesting about your platform/OS?
Tried ITK 5 today, same behavior.
Nothing very interesting AFAIK. Have tried this on RHEL 6.7 and CentOS 7.6, both in pretty much standard configurations.
Interestingly, I ran some tests and QThreads, pthreads and std::threads all behave properly in terms of getting scheduled across multiple CPUs, even within the same application process as the ITK stuff. So it doesn’t seem like a system or application-specific setting.
Could this maybe be an OpenMP thing?
ITK doesn’t really use OpenMP, due to lack of universal compiler support for it.