IPP 7.1 redist dll for Atom processors (Windows)

IPP 7.1 redist dll for Atom processors (Windows)

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

30 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di 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

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

Ritratto di 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

Ritratto di Thomas Jensen

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.

Ritratto di Thomas Jensen

I forgot to say, I use IPP 7.1

Ritratto di Sergey Kostrov

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

Ritratto di Sergey Kostrov

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.

Ritratto di 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 

Ritratto di Thomas Jensen

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

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

Ritratto di Thomas Jensen

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?

Ritratto di Sergey Kostrov

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

Ritratto di Thomas Jensen

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.

Ritratto di Sergey Kostrov

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

Ritratto di Sergey Khlystov (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 

Regards, Sergey
Ritratto di Thomas Jensen

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.

Ritratto di Sergey Khlystov (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 

Regards, Sergey
Ritratto di Thomas Jensen

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.

Ritratto di Thomas Jensen

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

Ritratto di Thomas Jensen

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

Ritratto di Sergey Khlystov (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 

Regards, Sergey
Ritratto di Thomas Jensen

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

Ritratto di Sergey Kostrov

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

Ritratto di Thomas Jensen

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.

Ritratto di Sergey Khlystov (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:

#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

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 

Regards, Sergey
Ritratto di Thomas Jensen

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

Ritratto di Sergey Khlystov (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 

Regards, Sergey
Ritratto di Thomas Jensen

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

Ritratto di Thomas Jensen

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

Accedere per lasciare un commento.