High CPU usage with OpenMP from latest Visual Studio Service Pack 1

[thevinn]

I upgraded my Visual Studio to Service Pack 1. My application previously saw tremendous benefit from OpenMP. Now, it is incredibly slow with OpenMP. The problem is that Microsoft introduced the following defect in its OpenMP shared libraries (.DLL):

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=481541

The problem exists even when the Intel C++ compiler is used to build the application.

While this is not directly a problem with the Intel C++ compiler, I am asking if it would be possible if Intel could provide a static library that provides the necessary OpenMP support, that does not have this defect. This would solve two problems, one the problem of high CPU usage, and two that activating OpenMP in an application forces you to link with the C runtimes as a shared library (since OpenMP is itself a shared library).

Requiring that an application use the shared library version of the runtime, is incredibly inconvenient. Some percentage of users always have trouble with the redistributables, and another portion of them eventually have a problem with the version numbers.

Providing the OpenMP support as a static library would be of tremendous value.

[Yuan_C_Intel · Accepted solution]

Quoting - thevinn

While this is not directly a problem with the Intel C++ compiler, I am asking if it would be possible if Intel could provide a static library that provides the necessary OpenMP support, that does not have this defect. This would solve two problems, one the problem of high CPU usage, and two that activating OpenMP in an application forces you to link with the C runtimes as a shared library (since OpenMP is itself a shared library).

Requiring that an application use the shared library version of the runtime, is incredibly inconvenient. Some percentage of users always have trouble with the redistributables, and another portion of them eventually have a problem with the version numbers.

Providing the OpenMP support as a static library would be of tremendous value.

Hi, thevinn

The Intel compiler do provide an option to link with static OpenMP run-time library and do provide several kinds of libraries to support OpenMP*.

See option:

-openmp-link, /Qopenmp-link
This option controls whether the compiler links to static or dynamic OpenMP run-time libraries. To link to the static OpenMP run-time library (RTL) and create a purely static executable, you must specify -openmp-link static (Linux and Mac OS X) or /Qopenmp-link:static (Windows). However, we strongly recommend you use the default setting, -openmp-link dynamic (Linux and Mac OS X) or /Qopenmp-link:dynamic (Windows).

Provided library category:

Performance: supports parallel OpenMP execution.
Profile: supports parallel OpenMP execution and allows use of Intel Thread Profiler.
Stubs: supports serial execution of OpenMP applications.

Each kind of library is available for both dynamic and static linking.

But static library is not recommended as: "they might cause multiple libraries to be linked in an application. The condition is not supported and could lead to unpredictable results."

More details on OpenMP support can be found from "Intel C++ Compiler User and Reference Guides", section: "Optimizing Applications".


Thank you.

[thevinn]

This is great news!! When you say "they might cause multiple libraries..." do you mean, that if I link with another static or shared library that uses OpenMP, I might get multiple instances of the OpenMP library? If the answer is yes, that is not a problem for me because I am only linking with my own libraries, and only one of them uses OpenMP.

Quoting - Yolanda Chen (Intel)

But static library is not recommended as: "they might cause multiple libraries to be linked in an application. The condition is not supported and could lead to unpredictable results."

[thevinn]

This worked, although it was strange that I had to add the flag to the compiler settings rather than the linker settings.

In the Release version of my program, compiled with Intel C++, I went from 320 million pixels per second without OpenMP, to 390 million pixels per second using OpenMP statically linked, a respectable improvement of 22%.

[thevinn]

Upon further inspection, the OpenMP version of my app is indeed consume way more CPU than it should. This leads me to believe that even when linking statically with OpenMP, the defect described in the original post regarding high CPU utilization still exists.

When I turn OpenMP off, my application no longer consumes very high CPU resources.

Now I realize that the only reason I got a 20% speedup is because my machine is so fast (8 cores) that despite the bug in the OpenMP library there is still an increase in speed from using OpenMP.

However, because the defect in the OpenMP library is causing high utilization it is unsuitable for my app.

I will be looking at TBB (Thread Building Blocks) to see if I can replace the OpenMP section with some TBB code. This will hopefully have the advantage of static linking.

[pvonkaenel]

Quoting - thevinn

Upon further inspection, the OpenMP version of my app is indeed consume way more CPU than it should. This leads me to believe that even when linking statically with OpenMP, the defect described in the original post regarding high CPU utilization still exists.

When I turn OpenMP off, my application no longer consumes very high CPU resources.

Now I realize that the only reason I got a 20% speedup is because my machine is so fast (8 cores) that despite the bug in the OpenMP library there is still an increase in speed from using OpenMP.

However, because the defect in the OpenMP library is causing high utilization it is unsuitable for my app.

I will be looking at TBB (Thread Building Blocks) to see if I can replace the OpenMP section with some TBB code. This will hopefully have the advantage of static linking.

Hi thevinn, nice to bump into you again (I just came from the TBB forum). I saw the same high CPU utilization with OpenMP - 95% and higher. When I switched to TBB 2.2 I saw that drop down to about 35%-45% with almost identical application performance. I think OpenMP tries to keep worker threads alive for a while instead of letting them block when there is no work. This way when there is work, there is no context switch. I think TBB does something similar, but it looks like they spin-wait for a much shorter time.

Just a guess though.

Peter

[TimP]

Quoting - pvonkaenel

I think OpenMP tries to keep worker threads alive for a while instead of letting them block when there is no work. This way when there is work, there is no context switch. I think TBB does something similar, but it looks like they spin-wait for a much shorter time.

If the spin-wait time is of interest, there are both environment variable and function call controls. Read the documentation, under OpenMP environment variables, sub-topic Intel extensions.