IPP 7.1 redist dll for Atom processors (Windows)

[Chew_E_]

Hi,

I downloaded an eval copy of IPP 7.1, the one included in Parallels Studio. According to this link (http://software.intel.com/en-us/articles/new-atom-support), I am expecting to have *s8-7.1.dll in my redist folder but the one I have doesn't. Is it a separate download? From the download page in Intel for eval, I only have download links for ia32, intel64 and linux which don't include dlls for Atom. Any help re this one would be appreciated. Thanks.

[Sergey_K_Intel]

Thomas,

In order to translate general IPP names to the names with correct prefix you can use just C preprocessor. Create a new exportdef.c file in your project with the following content (just an example from customdll sample):
///////
#include "ipp_s8.h"
EXPORTS
    ippiMomentInitAlloc_64f
    ippiMomentFree_64f
    ippiMoments64f_32f_C1R
////
I am assimung that you put all IPP generic function names from your IPP subset. Compile this file with "/E" option. In the output  window of MS Visual Studio you'll get preprocessed text, i.e text of export definitions file with generic names substituted with prefixed names from ipp_v8.h file. Copy these lines from output window to your real exports.def file and after linking you should get only s8-flavor functions in you custom DLL. May be this is not what you want, just simple method to do text substitution.

Regards,
Sergey 

[Thomas_Jensen1]

I'm confused. A file exportdef.c with EXPORTS in? EXPORTS is only for DEF files, no?
Visual Studio doesn't like a C file with EXPORTS.
Visual Studio doesn't like a DEF file with INCLUDE.

Maybe I can use DEF file with name substitute:
EXPORTS
  ippsAdd_8u = w7_ippsAdd_8u

[SergeyKostrov]

>>...Visual Studio doesn't like a C file with EXPORTS... This is a quote from MSDN about EXPORTS keyword: ... Introduces a section of one or more definitions that are exported functions or data. Each definition must be on a separate line. ... and it has to be used with DEF files only.

[Thomas_Jensen1]

In that case you are wrong when you suggest to create a file exportdef.c and putting the EXPORTS in it.

In any case, it seems you cannot put #include "ipp_s8.h" in it.

[Sergey_K_Intel]

No, no, no. Use C compiler as a text substitution tool. After you get preprocessed text in VS' output window, copy that text with EXPORTS + prefixed function names into real DEF file, remove your fiction C file from project and continue. This is for not wasting time finding correspondence between generic IPP names and their analogs in ipp_v8.h file.

Look what I have in my sample: customdef.c file with content:
[cpp]

#include "ipp_s8.h"
EXPORTS
   ippGetStatusString
   ippsGetLibVersion
   ippsMalloc_32f
   ippsFree
   ippsThreshold_32f_I
   ippsSum_32f
   ippiGetLibVersion
   ippiMomentInitAlloc_64f
   ippiMomentFree_64f
   ippiMoments64f_32f_C1R
   ippiGetSpatialMoment_64f

[/cpp]

I set in the properties of this particular file: "Configuration Properties\C/C++\Command Line" as "/E". Than hit Ctrl+F7 to compile current file (customdef.c in my case). In the output window I get lot of empty "1> " lines with the following in the end:

1> #line 2 "customdef.c"
1>
1> EXPORTS
1> ippGetStatusString
1> s8_ippsGetLibVersion
1> s8_ippsMalloc_32f
1> s8_ippsFree
1> s8_ippsThreshold_32f_I
1> s8_ippsSum_32f
1> s8_ippiGetLibVersion
1> s8_ippiMomentInitAlloc_64f
1> s8_ippiMomentFree_64f
1> s8_ippiMoments64f_32f_C1R
1> s8_ippiGetSpatialMoment_64f
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
 

Then I copy rest of Output window to my "exports.def" file, remove "1>    " at the beginning of each line with "Find and Replace" command, set "Configuration Properties\General\Excluded From Build: Yes" for "custodef.c" file to exclude it from project and rebuild my "customdll" project. Now it contains specialized "exports.def" file and resulting DLL contains only s8-flavor functions.

Regards,
Sergey 

[Thomas_Jensen1]

I think I have an almost workable workaround now, except possible for Atom. I let the DEF file alias every function like ippsAdd_8u = w7_ippsAdd_8u. However, for Atom (v8), of my 1700 used functions, about 800 actually uses s8, so my alias does not work.
And it is very awkward work to manually find those that need s8...

[Sergey_K_Intel]

Thomas, the "v8" prefix in "ipp_s8.h" file (the file that is usable for Atom arcthitecture) doesn't mean, that v8_* functions should not be used on Atom. That only means, that there is no Atom-specific optimization for this particular function. You may fearlessly use these v8*_ functions enlisted in ipp_s8.h file, they will work on Atom.

Regards,
Sergey 

[Thomas_Jensen1]

I understand what you write about using v8 with s8 CPU. I understand not everyting can be speficifically optimized for Atom.

As for my other problems, I decided to write a quick & dirty program that simply generates the proper DEF file, after scanning ipp_s8.h etc.
I now have a set of custom DLL files, one for each CPU, and containing my subset (1700 functions). It is linked to static-threaded libs.

I now continue to try to build a non-debug version using Intel C++....

[Thomas_Jensen1]

And it compiles also with Intel C++. Thanks for all input!

[DScat]

Hello to everybody:

first I must say that I am on Linux, but since I saw more or less the same issue, I will post it here (unless you tell me not to do so and open another thread).

I have the following problem:

I'm using an application that uses the ipp and performs a dynamic dispatching. The application is multiplatform (Windows/Linux). The thing is that the computer I use with Linux is an Atom and when the application starts I get the waterfall library loading problem (the computer with Windows is not an Atom one). I have no s8 libraries but v8. I don't know how to avoid the *s8.so libraries loading at runtime and load the v8 libraries instead.

I'm using the function ippInitCpu(). Could it be that I should use the ippInit() function instead?  Here a snippet of code:

IppStatus InitPreferredCpu(DString sCpu)
{
    if(sCpu.Size())
    {
        if(!sCpu.Compare(VM_STRING("SSE"), false))
            return ippInitCpu(ippCpuSSE);
        else if(!sCpu.Compare(VM_STRING("SSE2"), false))
            return ippInitCpu(ippCpuSSE2);
        else if(!sCpu.Compare(VM_STRING("SSE3"), false))
            return ippInitCpu(ippCpuSSE3);
        else if(!sCpu.Compare(VM_STRING("SSSE3"), false))
            return ippInitCpu(ippCpuSSSE3);
        else if(!sCpu.Compare(VM_STRING("SSE41"), false))
            return ippInitCpu(ippCpuSSE41);
        else if(!sCpu.Compare(VM_STRING("SSE42"), false))
            return ippInitCpu(ippCpuSSE42);
        else if(!sCpu.Compare(VM_STRING("AVX"), false))
            return ippInitCpu(ippCpuAVX);
        else if(!sCpu.Compare(VM_STRING("AES"), false))
            return ippInitCpu(ippCpuAES);
        else if(!sCpu.Compare(VM_STRING("AVX2"), false))
            return ippInitCpu(ippCpuAVX2);
    }
    return ippInit();
}

Any help would be appreciated.

Thanks in advance.

[Igor_A_Intel]

Hi Scati,

dynamic libraries are dispatched automatically at dllmain() function execution, therefore there is no sense to call ippInit() for dynamically linked IPP libraries - the result will be the same... To avoid the automatic dispatching and search for S8 library you should link IPP libraries statically. In this case you can use ippInitCpu instead of ippInit and avoid automatic search for the best library version.

regards, Igor

[DScat]

Hi Igor and thanks for the answer,

I understand what you say. Using the v8 library is not my choice, but the IPP library tries to load the s8 libary and is nowhere to be found. Is there any solution to solve this problem without changing the dispatching (i.e linking) mode?

regards, Scati

[DScat]

Hi again Igor,

I followed your instructions and made a little change in the code I posted before. Now I check if the cpuType is "ippCpuBonnell", the one that identifies the Atom processor. In this case I call the ippInitCpu passing the cpuType as "ippCpuSSSE3". Am I right?

Thanks

[Igor_A_Intel]

Hi Scati,

yes, you are right. And the best solution is to switch to the most fresh IPP version -- it doesn't have such issues as has implemented internally so called "smart dispatching" - s8 and v8 code are merged into one single library and is dispatched based on current CPU architecture and pre-measured performance tables: this means that on Atom CPU for function "A" can be dispatched s8 code while for some function "B" - v8.

regards, Igor.