Multiple Custom DLL static-threaded: how to link to ippcore?

Multiple Custom DLL static-threaded: how to link to ippcore?

I have a project with a front DLL with common code and a CPU dispatcher, and then a set of custom DLL's, one for each CPU flavor.

The front DLL is called single-threadedly from an application.

One function in the front DLL is the IPP Jpeg Codec, which is threaded.
The Jpeg Codec in the front DLL calls IPP functions in the custom DLL of the currently loaded CPU flavor.

The openmp support DLL "libiomp5md.dll" is linked to dynamically, so my front DLL and my CPU DLL both use it.

But what about ippcore? Since I link to static-threaded, I specify ippcore_t.lib, both in the front DLL and in each CPU DLL.
But then the front DLL will implement its own ippcore and the CPU DLL also its own. Shouldn't those use the same ippcore, and then I must specify not ippcore_t.lib (static) but ippcore.lib (dynamic) ?

Who kowns about this difference of ippcore usage?

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

>>But then the front DLL will implement its own ippcore and the CPU DLL also its own. Shouldn't those use the same ippcore, and
>>then I must specify not ippcore_t.lib (static) but ippcore.lib (dynamic)?..

Of course, some differences are possible between codes in the Dynamic Link Library ( ippcore.dll ) and the Static Link Library ( ippcore_t.lib ). However, only intensive testing could answer your question about differences and I would expect for 99.99% everything will work properly. If you find some issue(s) simply report for investigation.

Hi Thomas,

the most correct way is to use 1 instance of ippCore - so you should link it dynamically. ippCore has internally several global vars such as current index for dispatcher, cpu_features, enabled_cpu_features, may be something else. Imagine that when ippCore is linked statically to each your dll, imagine that in one dll you call ippInit and not in other - you'll have different cpu dispatched in each dll. each instance of ippCore will have it's own state because it has its own independent data segment.

Regards, Igor

I understand that linking to a single instance of ippcore is the proper way.

One question, since there are both ippcore_t.lib (threaded) and ippcore_l.lib (unthreaded), implying a difference in threading, then how do I "tell" ippcore.lib (dynamic) that I want threaded code? (well, apart from calling setnumsthreads of course!)

Just so you understand: I use my own dispatcher, not the one in ippcore (to get a much smaller subset).

>>...then how do I "tell" ippcore.lib (dynamic) that I want threaded code?..

I think it depends on used linking model and it is related to /Qipp compiler option ( of course, Not related to /MD or /MT options ).

For argument's sake, when using dynamic linking (ippcore.lib), and then ippcore71.dll and all the other waterfall dlls, is there a selection between threaded and non-threaded at all?

I see there is for static linking.

>>...is there a selection between threaded and non-threaded at all?

I think yes:
...
/* ////////////////////////////////////////////////////////////////////////////
// Name: ippSetNumThreads
//
// Purpose:
//
// Return:
// ippStsNoErr Ok
// ippStsNoOperation For static library internal threading is not supported
// ippStsSizeErr Desired number of threads less or equal zero
//
// Arguments:
// numThr Desired number of threads
*/
IPPAPI( IppStatus, ippSetNumThreads, ( int numThr ) )
...

If you call ippSetNumThreads( 1 ) then processing has to be single-threaded.

Leave a Comment

Please sign in to add a comment. Not a member? Join today