IPP 7.1 redist dll for Atom processors (Windows)

IPP 7.1 redist dll for Atom processors (Windows)


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.

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

Hi Chew,

Sorry, it seems the artice need to be updates for 7.1. You can use *v8 and *u8 for Atom pocessor. If you have install IPP 7.1. Please see the IPP userguide=> section of Dispatching


IA-32 Intel® architecture

Optimized for processors with Intel® Streaming SIMD Extensions 2 (Intel® SSE2)

Optimized for the Intel® Atom™ processor and processors with Intel® Supplemental Streaming SIMD Extensions 3 (SSSE3)

Optimized for processors with Intel SSE4.1, SSE4.2, and Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI)

Optimized for processors with Intel AVX and AES-NI

Optimized for processors with Intel® Advanced Vector Extensions (Intel® AVX2)

Intel® 64 architecture

Optimized for processors with Intel SSE3

Optimized for the Intel® Atom™ processor and 64-bit applications on processors with SSSE3

Optimized for 64-bit applications on processors with Intel SSE4.1

Optimized for processors with Intel AVX instruction set

Optimized for processors with Intel AVX2

Hi Ying,

Thank you for your reply. Yes, I actually referred to that document and was hoping that I will be dispatched to v8 as I'm doing my tests in 32bit only. So far, all I can get is the waterfall error which means (based on .h comments), required dll was not found. So I though it must be that s8 dlls, specifically ippccs8-7.1.dll. I also tried the static linking using the static libs and ipp_s8.h and it seems to work just fine. However, I really want the dynamic dispatching since I will be supporting multiple CPUs.

HI Chew,

if you are building an IPP application that will be run on multiple processor platforms, including Atom processors, the v8.dll can be used too.

The s8.dll was removed as we adopt smart dispatcher internally in order to reduce the size of library since 7.1. But the performance shoud keep same.

Please see <>. (We have such idea (smart dispatcher and reduce the library size) since ver. 6, but implement gradually)

However, you do not need to use this Atom-specific library if you are building an IPP application that will be run on multiple processor platforms, including Atom processors. This Atom-only version of the library is provided as a convenience for building IPP applications that will run ONLY on an Atom, as opposed to IPP applications that may run on a variety of processor platforms.

The fundamental difference between the s8/n8 and v8/u8 libraries are the compiler options used to build them, which accommodates the differences in the construction of the instruction pipelines between the Atom and other SSSE3 processors. Both libraries are Supplemental SSE3 libraries and the s8/n8 version of the IPP library does not use any Atom-unique instructions, so no features are lost by running the v8/u8 slice of the library on an Atom processor. Also, these two variations in the library (s8/n8 and v8/u8) give nearly identical performance on an Atom>>

Best Regards,

I have a problem with using V8 (Atom) using static threaded linking.

All symbols I use are undefined. For instance, I link to ipps_t.lib and this contains the function v8_ippsRShiftC_32s but my linker can't find it.
Linking with W7 (SSE2) works fine.

I forgot to say, I use IPP 7.1

>>...Linking with W7 ( SSE2 ) works fine...

Thomas is absolutely correct.

Last week I completed a set of tests with ippsAdd_32f and ippsSub_32f IPP functions from IPP DSP domain on a system with:
CPU Brand String: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
CPU Vendor: GenuineIntel
Stepping ID = 2
Model = 12
Family = 6
Extended Model = 1
CLFLUSH Cache Line Size = 64
using w7 IPP DLLs. These DLLs will allow you to complete all eveluations you need and later you could tune up your application for a different set of DLLs ( these DLLs are called Waterfall DLLs ).

Take into account that an application Does Not Need to be re-compiled if a dynamic linking was used and only Waterfall DLLs need to be replaced (!).

Here are some additional technical details for the CPU I used in my tests:
CPU Vendor: GenuineIntel
HTT and Streaming SIMD Extensions features:
HTT : 1
MMX : 1
SSE : 1
SSE2 : 1
SSE3 : 1
SSSE3 : 1
SSE4.1: 0
SSE4.2: 0
Try to get a list of all supported Intel instruction sets for a target CPU.

Hi Thomas,

Not sure how do you do the test. Could you please send a small test case?

Regarding the smart dispatch of v8 and s8, there are a function lists in C:\Program Files (x86)\Intel\Composer XE 2013\ipp\tools\ia32\staticlib and you need to include the ipp_s8.h before other IPP header file.

Best Regards,


I don't have a small test case right now.

However, I think I now understand the problem. First, I was not aware of the folder ipp\tools\ia32\staticlib.
I now see that it contains remapping function lists of ALL IPP functions... And for Atom (S8), it sometime maps a function to S8 and sometimes to V8. That is the cause of my problem, since I don't use these remapping files. I use a maco that remaps to a single target, S8 or V8 etc., so that is why it gives linking errors in either case.

I "just" have to drop my macro implementation and start using your function remapping files. I guess those files will be kept updates in the future? :)

Hi Thomas,

Right, i guess that is the reason.  yes, the files will be kept updates at least in the next release IPP 8.0.

Best Regards,


I just got my code working using the remapping files in ipp\tools\ia32\staticlib.

However, now I got a new problem: the custom DLL I create now exploded in size from 7.5MB to 41MB.
It must be from the fact that the remapping list references ALL functions in IPP, even if I use IPPAPI( type,name,arg ) __declspec(dllexport) type __STDCALL ##name arg, with a REDUCED list of functions.

In fact, the only reference I have are those from my DEF file.

Can you indicate how I can create a custom static DLL using only a subset defined via funclist.h and also using ipp\tools\ia32\staticlib?

>>... the custom DLL I create now exploded in size from 7.5MB to 41MB...

Try to use a linker option /OPT:REF since it removes Not referenced functions, data and variables.

Note: This is in case of a MS's linker.

I use MS for development and debugging, and Intel Compiler for release.
The problem I describe is both with MS and with Intel Compiler.

With MS, I do have /OPT:REF in my configuration. I say the problem first in MS.
Stil, the only reference is in the DEF file, since the DLL only contains select IPP functions for one CPU only, and a DEF to publish it.
The question is then, how can the size increase so much?

The function remapping H files actually only contains macros who add a specific CPU prefix to any IPP function call.
Thus it should not affect anything.

>>...The question is then, how can the size increase so much?..

Thomas, try to use dumpbin.exe or lib.exe utilities ti analyze the content of that DLL.

For example, lib.exe has the following options:

Microsoft (R) Library Manager Version 8.00.40310.39
Copyright (C) Microsoft Corporation. All rights reserved.

usage: LIB [options] [files]



Hi Thomas.

Have you looked at "advanced-usage/customdll" sample?

Having this sample, what else do you need? To build custom DLL for selected CPU architectures only?


Dumpbin /exports indicates that I have about 1700 functions in the DEF file, which is correct (my IPP subset).
The function remapping files has about 11500 functions, which is the full IPP set.

And yes, I have looked at the customdll sample which is in ipp-samples\sources\advanced-usage\core\customdll\src (IPP 7.1).
I fully understand that for a custom DLL, you basically include ipp.h and then simply specify which IPP functions you want to have in the DLL by adding entries to the DEF file.
This is also what I'm doing in the 5.3, 6.1, 7.0 versions of my custom DLL project. However, when I now wanted to implement Atom-specific CPU, I quickly found out that I must include a file from staticlib, and with that, my DLL exploded in size.

I will continue to search for a solution today.


In you custom DLL you don't need all function clones for CPU archs other than Atom. So, if you want 1700 IPP functions you should have 1700+something entries in DLL.

I am afraid that if you add a single entry to DEF file with basic name (say, ippsAdd_8u), you get all clones (w7_ippsAdd_8u, v8_ippsAdd_8u, s8_ippsAdd_8u ...) in DLL. This is because the general IPP function name is used in DEF file. You should use specific names (e.g. s8_ippsAdd_8u) only in the DEF.

But this adds the limitation, that your target applications should use "#include ipp_s8.h" everywhere instead of "#include ipp.h". Otherwise, the compiler will generate calls to the functions, which are absent in your custom DLL.


I see that one of my DLLs (w7) does indeed have CPU code for v8, s8 etc. instead of only w7 code.
I then need to know why all CPU flavors are linked when I declare ippsAdd_8u in DEF. Why do I also get v8_ippsAdd_8u (and the others too) when I declare ippsAdd_8u and I only read ipp_w7.h? In ipp_w7.h, ippsAdd_8u is translated to w7_ippsAdd_8u.

Is it something in the LIB files that I don't understand? I use ipps_t.lib, ippi_t.lib etc.

If I must use CPU specific prefixes in my DEF, like w7_ippsAdd_8u, then I will get a problem with Atom (only).

For all CPU flavors except Atom optimized, all prefixes are the same.
But for Atom optimized, the prefix is sometimes s8_ and sometimes v8_. The remapping file is ipp_s8.h, but inside this file, many functions map to v8_ (ssse3 or Atom non-optimzied).

This means that I should put a mix of s8_ and v8_ in my DEF file, which breaks my setup.
My old setup does indeed have w7_ etc as prefix in DEF, but now I thought, I can use the (new) remapping files ipp_s8.h and let it remap DEF (no prefix) to lib (mixed prefix).

I now used dumpbin on ipps_t.lib and indeed now see that it contains all CPU references. I now understand that I cannot use function references without prefixes when I use static linking for a single CPU only.

That means going back to putting prefixes in DEF, which is not a problem for non-Atom, but is for Atom because it uses a mix of s8 and v8.
I can manually put in the mix of prefixes in DEF, but I also have __declspec(dllexport) in CPP files, and there I just use a redefined IPPAPI macro, but that only works with a single prefix...


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"
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.


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:
  ippsAdd_8u = w7_ippsAdd_8u

>>...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.

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.

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:

#include "ipp_s8.h"

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> 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.


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...

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.


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++....

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

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.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.

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

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

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?


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.

Leave a Comment

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