Latest version of libiomp5md creates instability in an established application
I’m 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 E5649’s @
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 can’t
bring up Task Manager, I can’t 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 CPU’s 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
| 