Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
6704 Discussions

Can I do a delayed load of libiomp5md.dll?

Mark_Rubelmann
Beginner
440 Views
Hi,

First of all I should say that I'm using IPP 7 with static linking in M$ Visual Studio 2008. At the moment I'm dynamically linking libiomp5md.dll but the default implicit linking is turning out to be a problem because of a distribution issue. (I can't easily install the dll in one of the places that Windows knows to look for it.) I'd like to try using delayed loading to work around the problem but so far I haven't been able to get it to work. Does anyone know if that's even possible to do? I'm getting the following warning:

LINK : warning LNK4199: /DELAYLOAD:libiomp5md.dll ignored; no imports found from libiomp5md.dll

and about a million errors similar to this from a .lib that's linked into my project and also uses OpenMP:

error LNK2001: unresolved external symbol __You_must_link_with_Microsoft_OpenMP_library

Another possibility might be to statically link libiomp5mt.lib but I'm pretty confused about it and haven't tried it yet. After searching through the forums on here, it sounds like there can be problems when more than one instance of OpenMP is being run in the same process but I'm not sure what that actually means or how it happens. Is it a linker thing or will there be a chance for subtle runtime bugs? Right now I've got a mixture of LIBs and DLLs that all use both IPP and OpenMP directly. They get mashed together into another DLL. Would I be getting into that mysterious OpenMP problem if I start linking libiomp5mt.lib statically? If I were to switch those DLLs over to LIBs and just link *everything* statically, would that fix it?

I hope some of that made sense...

Thanks,
Mark
0 Kudos
1 Solution
PaulF_IntelCorp
Employee
440 Views
Hello Mark,

Your confusion is well founded, the linkage issues you are dealing with are not obvious. Try these threads:

http://software.intel.com/en-us/forums/showthread.php?t=81831

http://connect.microsoft.com/VisualStudio/feedback/details/633585/openmp-omp-h-does-not-enable-linking-to-vcomp-d-lib-file-if-openmp-support-is-enabled

they might help provide some useful help.

Regarding the difference between using the dynamic version of OpenMP and the static version -- but provide identical functionality, so your application will work properly with either one. The assumption is that if you use the dynamic version of the library you are less likely to encounter a situation where two different applications (say one from you and one from someone else) each load a separate instance of the OpenMP library and then compete forprocessor thread resources (the CPU cores). In reality this problem can still occur even when using the dynamic libraries -- two different versions get loaded, or the Microsoft OMP library gets used by the "other guy's app" and the Intel OMP library gets used by "your app."

Given the issues you are having, I would go ahead and link with the static version of the Intel OpenMP library (you need to use that one with IPP) and see if your builds work and your app runs properly. This works as long as you believe the risk of a competing OpenMP library being loaded by a competing application the same system is low.

Another thing to look at is which IPP functions you are using and whether or not they even are multi-threaded. If none of the functions you are using are multi-threaded, you can just link against the single-threaded library and eliminate OpenMP from the equation. About 85% of the functions ARE NOT threaded. But if you link against the multi-threaded library you'll still end up including the OpenMP library in your build because of some initialization routines in the library -- so the fact that you need to link in the OpenMP library does not necessarily mean that your IPP functions are using it. Check the "ThreadedFunctionsList.txt" file (typically located here C:\Program Files (x86)\Intel\ComposerXE-2011\Documentation\en_US\ipp) on your development system.

If you find that only one or two functions are threaded you might have to do some testing to see if the threading is giving you any advantage. For some functions and/or data sets the threading provides a huge speedup, for some it does not. For example, small vectors may not benefit greatly from threading, but operating over large images, for example, ususally do benefit.

Hope this helps,

Paul

View solution in original post

0 Kudos
6 Replies
PaulF_IntelCorp
Employee
441 Views
Hello Mark,

Your confusion is well founded, the linkage issues you are dealing with are not obvious. Try these threads:

http://software.intel.com/en-us/forums/showthread.php?t=81831

http://connect.microsoft.com/VisualStudio/feedback/details/633585/openmp-omp-h-does-not-enable-linking-to-vcomp-d-lib-file-if-openmp-support-is-enabled

they might help provide some useful help.

Regarding the difference between using the dynamic version of OpenMP and the static version -- but provide identical functionality, so your application will work properly with either one. The assumption is that if you use the dynamic version of the library you are less likely to encounter a situation where two different applications (say one from you and one from someone else) each load a separate instance of the OpenMP library and then compete forprocessor thread resources (the CPU cores). In reality this problem can still occur even when using the dynamic libraries -- two different versions get loaded, or the Microsoft OMP library gets used by the "other guy's app" and the Intel OMP library gets used by "your app."

Given the issues you are having, I would go ahead and link with the static version of the Intel OpenMP library (you need to use that one with IPP) and see if your builds work and your app runs properly. This works as long as you believe the risk of a competing OpenMP library being loaded by a competing application the same system is low.

Another thing to look at is which IPP functions you are using and whether or not they even are multi-threaded. If none of the functions you are using are multi-threaded, you can just link against the single-threaded library and eliminate OpenMP from the equation. About 85% of the functions ARE NOT threaded. But if you link against the multi-threaded library you'll still end up including the OpenMP library in your build because of some initialization routines in the library -- so the fact that you need to link in the OpenMP library does not necessarily mean that your IPP functions are using it. Check the "ThreadedFunctionsList.txt" file (typically located here C:\Program Files (x86)\Intel\ComposerXE-2011\Documentation\en_US\ipp) on your development system.

If you find that only one or two functions are threaded you might have to do some testing to see if the threading is giving you any advantage. For some functions and/or data sets the threading provides a huge speedup, for some it does not. For example, small vectors may not benefit greatly from threading, but operating over large images, for example, ususally do benefit.

Hope this helps,

Paul
0 Kudos
Mark_Rubelmann
Beginner
440 Views
Thanks Paul! Yes, that's very helpful. I'm still a little puzzled about the multiple OpenMP instance thing though... If OpenMP is being used in two different processes, how could they affect each other? They're certainly going to be competing for CPU time but isn't that entirely up to the task scheduler? I don't see how the OpenMP library could have anything to do with that. If there's just one copy of the library loaded, does it do some sort of inter-process communication to take advantage of something?

I'll go ahead and try static linking. That'll greatly simplify things! We definitely need OpenMP because we do a lot of our own threading using it.

Thanks,
Mark
0 Kudos
PaulF_IntelCorp
Employee
440 Views
Hello Mark,

If you have two instances of OpenMP running simultaneously on a single machine they will be competing for more than CPU time, they're also competing for CPU cores in the form of task threads. I don't understand the details of how the thread dispatch engine works, but it doesn't rely on the OS to provide scheduling services (directly, that is; ultimately, the OS does provide services of some sort to the OpenMP engine). The current version of the OpenMP lib assumes it has all CPU resources to use as a monopoly -- it doesn't like to share. This makes sense since it was developed for supercomputing applications that generally have all the resources of a machine available when they run.

Some other threading techniques, such as that implemented by Cilk, use a "resource stealing" technique that adapts more readily to other multi-threaded activities on the CPU -- it shares more readily. This is fine when you are not doing any heavy duty work, but the drawback to this technique is that when you do want all the cores on the machine you may not get them; if some other task is busy with some of the cores you may end up with fewer than you planned.

Seems there's no perfect solution for all situations.

Regards,

Paul
0 Kudos
Mark_Rubelmann
Beginner
440 Views
Argh, I can't get this thing to properly link now that I'm trying static linking. My problem is that I've got two libraries, one of which is a .lib that's used by a .dll. (The .dll is my main project.) Both of them use OpenMP so right now I've got both of them linking to libiomp5mt.lib and have them set to ignore vcomp. I'm getting lots of warnings from functions that are calling omp functions. For example:

warning LNK4217: locally defined symbol _omp_get_num_threads imported in function "int __cdecl SomeFunction(void)"

I think it works if I have the .lib use vcomp instead of libiomp5mt but this article makes it sound like that'll be problematic: http://software.intel.com/en-us/articles/openmp-support-change/

Any idea what I'm doing wrong? Or is using vcomp in the .lib the correct thing to do?

Thanks,
Mark
0 Kudos
PaulF_IntelCorp
Employee
440 Views
Hello Mark,

You might want to take this issue to the compiler forum and/or the HPC forum where they have far deeper experience with the OpenMP library and issues related to using the Intel OpenMP library. Those forums can be found here:

Intel C++ Compiler
Intel Clusters and HPC Technology

Sorry we're not able to resolve it any further on this forum.

Paul
0 Kudos
Mark_Rubelmann
Beginner
440 Views
Paul,

Thanks for the suggestion. I actually worked around the issue by switching over to the single-threaded IPP libraries and going back to M$'s OpenMP. Not the ideal solution but oh well.

Thanks,
Mark
0 Kudos
Reply