Latest version of libiomp5md creates instability in an established application

[John_S_18]

Im seeking technical support with regard to the IPP library as relates to the latest version of libiomp5md.dll [v5.0.2011.606, 12 Aug 11], originally shipped with IPP v7.0.4.221. I am currently using IPP v7.0.5.233, which also uses the *.606 version of libiomp5md.dll. This latest version of the Intel OpenMP libraryl has created great instability and unpredictability in a very established code base of mine.

Background:

I have been using IPP for over 3 years since v5.2, primarily drawing from the ippi and ipps libraries for a Windows-based instrument control application written in native [MFC] C++. I have upgraded IPP many times without incident, but the latest two versions have been very problematic. The problem has been traced to the version of libiomp5m.dll deployed with the latest two IPP releases [7.0.4.221 and 7.0.5.233]. When I simply substitute the previous version of libiomp5m.dll [v5.0.2011.325, 28 Apr 11] at runtime, application stability is restored. Note that the application was linked against v7 Release 5 libraries, but the v*.325 libiomp5md.dll released with IPP v7.0.4.196 must be used at runtime.

Environment:

Here are some details about the development and runtime environments.

Compiler

o Microsoft v10.0

IDE

o VisualStudio 2010 SP1

Runtime Environments:

1. Single CPU configuration using Xeon X3450 @ 2.67GHz; 10 GB RAM

2. Dual-CPU configuration using Xeon E5649s @ 2.53GHz; 10 GB RAM

OS

o Window 7 Professional, SP1 [all Windows Updates run to date]

Application

o MFC C++ application

o multi-threaded with dynamic linking to Windows runtime DLLs and to IPP DLLs

o relies solely on libiomp5md for its OpenMP implementation and is built with flags that instruct the complier to ignore the Windows OpenMP runtime libraries (vcomp100.dll and vcompd.dll).

o compiled to use SSE2 optimization, but the stability problem is not a function of this optimization setting.

o typically 4 threads running simultaneously that make calls to the IPP library. Note that the code has operated stably with this architecture for many years now; IPP is advertised as a thread-safe library and has worked as advertised for > 3 years until now.

o because of the observed instability, the number of IPP threads has been set to a value of 1 (unity) via a call to the ippSetNumThreads(). So, in theory none of the threaded IPP functions that I might be calling are even operating with threading optimization.

Unstable Behavior:

There are a few relevant observations that I can share:

1. v5.0.2011.606 creates a runtime instability in my software that is very difficult to explain. When running in the VS2010 SP1 debugger, the code eventually hangs, causing one of my threads to simply stop executing dead in its tracks. I can zero in on the exact line of code beyond which it stops executing; the thread simply stops stepping through the compiled code at that point.

2. When a Release mode version of my code is run, the behavior is much worse. The threads stops executing (hanging my application), but what is worse is that Windows becomes severely crippled as well! I cant bring up Task Manager, I cant open the management console or Control Panel, etc. All I can do is browse folders in Explorer, and the only way to recover is to take the system down by holding the on/off button. Meanwhile, my application has not crashed in any way other than the deadlock created by the thread that stops executing code.

3. When I monitor CPU usage per core using Windows Resource Monitor [CPU tab] I notice a dramatic difference between the v*.606 and the v*.325 libraries. Regardless of which hardware configuration I used, the older v*.325 library measures CPU usage at an average rate of about 55% for each core displayed (hyper-threading doubles the core count). In this case the individual real-time plots of CPU usage per core are very correlated with each other. However, when the newer v*.606 library is used, the average CPU usage drops dramatically to around 8%, with some cores nearly idle; This efficiency is a desirable performance trait of the latest library, which make me want to migrate to a stable version of your OpenMP library.

Question:

I think the fundamental question that can initiate this tech support request is: what exactly was changed in libiomp5md.dll between versions 5.0.2011.325 and 5.0.2011.606, especially as might relate to the Xeon CPUs that I am currently using? The instability and dramatic difference in Windows Resource Monitor CPU metrics leads me to believe that this OpenMP library was significantly rearchitected. From there we can discuss how to restore runtime stability to my code and the OS. And I wonder if my problem is at all related to this issue submitted a month ago to the Intel Compiler Forum: http://software.intel.com/en-us/forums/showthread.php?t=86406

==

Thank you for reading this and I hope you will take this report seriously. I can provide details as required, but will be unable to send the application as it is strongly tied to instrument hardware and cannot operate as a standalone application.

Regards,

John

[Ying_H_Intel]

Hi John,

The libiomp5md.dll is Intel OpenMP run-time library which isfrom Intel Compiler. The main change between v5.0.2011.606, 12 Aug 11 and libiomp5m.dll [v5.0.2011.325, 28 Apr 11] is that
>>
in that thread the changes in libiomp5md were in dropping blocktime to 0 from default 200 on oversubscribed system.

Old library didn't do this and caused the problems in real oversubscription cases. if there is no real oversubscription, it is better to keep blocktime with some reasonable value, not 0. but it is not simple for the library to distinguish "real" oversubscription from "virtual" when most threads are sleeping, so

Soyou may
1) try setting the blocktime at the beginning of the application via either environment variable or API call, and try latest OpenMP library, e.g.

set KMP_BLOCKTIME=200
or
kmp_set_defaults("KMP_BLOCKTIME=200");
or
kmp_set_blocktime(200);

We expect that it should behave similar to the 20110325 default behavior after that.

>>

Here is blocktime description in Intel Compiler documentation
<<>.=> Setting Environment Variables

2) or if you worked on multithreads envionment, may you pleasetryto link ippserial static library, likeipps_l.lib ippi_l.lib orinsert ippSetNumThreads(1) before IPP call.( They will not uselibiomp5md.dll.)
and see if the probleminsist?

Please See Simplified Link Instructions for the IPP Library - Intel Software Network
Threading and Intel Integrated Performance Primitives - Intel Software Network

Best Regards,
Ying