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.

[Ying_H_Intel]

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 Thanks Ying IA-32 Intel® architecture w7 Optimized for processors with Intel® Streaming SIMD Extensions 2 (Intel® SSE2) v8 Optimized for the Intel® Atom™ processor and processors with Intel® Supplemental Streaming SIMD Extensions 3 (SSSE3) p8 Optimized for processors with Intel SSE4.1, SSE4.2, and Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI) g9 Optimized for processors with Intel AVX and AES-NI h9 Optimized for processors with Intel® Advanced Vector Extensions (Intel® AVX2) Intel® 64 architecture m7 Optimized for processors with Intel SSE3 u8 Optimized for the Intel® Atom™ processor and 64-bit applications on processors with SSSE3 y8 Optimized for 64-bit applications on processors with Intel SSE4.1 e9 Optimized for processors with Intel AVX instruction set l9 Optimized for processors with Intel AVX2

[Chew_E_]

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.

[Ying_H_Intel]

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, Ying

[Thomas_Jensen1]

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.

[Thomas_Jensen1]

I forgot to say, I use IPP 7.1

[SergeyKostrov]

>>...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 (!).

[SergeyKostrov]

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.

[Ying_H_Intel]

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,

Ying 

[Thomas_Jensen1]

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? :)

[Ying_H_Intel]

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,

Ying.

[Thomas_Jensen1]

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?

[SergeyKostrov]

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

[Thomas_Jensen1]

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.

[SergeyKostrov]

>>...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: ..\PlatformSDK\Bin\win64>lib.exe Microsoft (R) Library Manager Version 8.00.40310.39 Copyright (C) Microsoft Corporation. All rights reserved. usage: LIB [options] [files] options: /DEF[:filename] /EXPORT:symbol /EXTRACT:membername /INCLUDE:symbol /LIBPATH:dir /LIST[:filename] /LTCG /MACHINE:{AM33|AMD64|ARM|CEE|EBC|IA64|M32R|MIPS|MIPS16|MIPSFPU|MIPSFPU16| MIPSR41XX|SH4|SH5|THUMB|X86} /NAME:filename /NODEFAULTLIB[:library] /NOLOGO /OUT:filename /REMOVE:membername /SUBSYSTEM:{CONSOLE|EFI_APPLICATION|EFI_BOOT_SERVICE_DRIVER| EFI_ROM|EFI_RUNTIME_DRIVER|NATIVE|POSIX|WINDOWS| WINDOWSCE}[,#[.##]] /VERBOSE

[Sergey_K_Intel]

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?

Regards,
Sergey 

[Thomas_Jensen1]

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.

[Sergey_K_Intel]

Thomas,

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.

Regards,
Sergey 

[Thomas_Jensen1]

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.

[Thomas_Jensen1]

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

[Thomas_Jensen1]

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