Note: The feature described in this article is only relevant if you need to deploy your Intel IPP application on platforms that do not support at least SSE2 for an IA-32 (32-bit) application or at least SSE3 for an Intel64 (64-bit) platform.

If all of your platforms support at least SSE2 (32-bit) or SSE3 (64-bit) you do not need to use the procedure described in this article and you do not need to download the generic px/mx static library!

If you are unsure what level of SIMD instructions your target platform(s) support, please visit ark.intel.com and search for your specific processor(s).

Unlike the dynamic library, the automatic dispatcher in the static library will not recognize the generic library and will not automatically dispatch to the generic optimizations provided in the generic px/mx add-on static library; instead, you must call the generic functions directly using the px_/mx_ prefix (as if you were calling an optimized library function directly). This means that if you choose to include the generic static library as part of your application you must decide whether to call the dispatched library or the equivalent generic library function at each Intel IPP function call within your application. Such a decision should be based on an initial evaluation of the platform that determines if you need to use the generic static library functions or if it is safe to call the standard dispatched library functions.

Note: The ippInit() function normally used to initialize the static library dispatcher determines the level of SSE instructions supported on the target processor at runtime using the CPUID instruction.

The manufacturer string returned by the CPUID instruction is not used as part of this test; however, the CPUID results are interpreted according to Intel processor conventions.

This means that if a non-Intel processor reports the SIMD instructions it supports in a way that is compatible with an Intel processor, the test passes (assuming the reported SIMD level is supported by the library); if not, the test fails. It is believed, but cannot be proven, that all x86-compatible processors report their support for SSE2 and SSE3 in a manner that is compatible with Intel processors. After SSE3 (e.g., SSSE3, SSE4.1, etc.) the SIMD instruction sets in use diverge across manufacturers and are, generally, not compatible with the Intel SSE (and AVX) instructions.

Additionally, at this time we are not planning to restore the generic optimization library as an integral dispatched layer within the Intel IPP product. We periodically must make some difficult choices regarding what we can continue to optimize, test and validate. Given that the SSE2 instruction set has been supported by nearly every x86-compatible processor produced for nearly a decade, the number of platforms that cannot run an application that employs the Intel IPP 7.0 library today is very, very small. The generic px/mx layers are still integrated in the 6.1 version of the Intel IPP library.

Please refer to our Optimization Notice for more information regarding performance and optimization choices in Intel software products.

Calling the Generic PX/MX Functions in an Application

With this version of the px/mx generic add-on static library you can now call the generic functions within the same application as you call the dispatched functions. You must, however, implement an additional layer that "manually dispatches" between the generic functions and the standard functions, since the static library dispatcher cannot, for technical reasons, be integrated with the generic px/mx static add-on library. (This is not an issue with the standard dynamic library.)

The basic idea is best shown by a simple example for use with the px (32-bit) version of the generic static library:

#include "ipp.h"
#include "ipp_generic.h"

Ipp64u ipp_cpuid = 0 ;
IppStatus ipp_init_status = ippInit() ;

// determine processor type/status and set "ipp_cpuid"
// see SIMD detection example further in article...

char src[] = "to be copied\0" ;
char dst[256] ;

if( ipp_cpuid < ippCPUID_SSE2 )
  status = px_ippsCopy_8u( src, dst, strlen(src)+1 ) ;
else 
  status = ippsCopy_8u( src, dst, strlen(src)+1 ) ;

In the example above, during initialization you must determine whether the application should use the “generic” px code or the standard library. If the runtime processor only supports SIMD instructions less than SSE2 (for example, the processor only supports MMX or SSE) the application calls the generic px functions; otherwise, it calls the standard library functions.

If you are writing a 64-bit application you use the mx prefix on the generic function call and the conditional check is against ippCPUID_SSE3, since SSE3 is the minimum level supported by the standard dispatched library (SSE2 is the minimum level supported by the 32-bit library).

Building Your Generic Include File

The example above includes a file called "ipp_generic.h," which is not distributed with either the standard product or the add-on generic library. You must build this include file for use with your application.

For example, assume that you are using all of the ippsCopy() functions. In that case you would copy from the standard ipps.h header file the function declarations for the ippsCopy() functions you are using. Then add "px_" (or "mx_" for 64-bit applications) to the name of each function declaration. This will provide you with the external function declarations you need in order to call the generic functions. In this case, ipp_generic.h would look like:

IPPAPI(IppStatus, px_ippsCopy_8u,( const Ipp8u* pSrc, Ipp8u* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_16s,( const Ipp16s* pSrc, Ipp16s* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_16sc,( const Ipp16sc* pSrc, Ipp16sc* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_32f,( const Ipp32f* pSrc, Ipp32f* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_32fc,( const Ipp32fc* pSrc, Ipp32fc* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_64f,( const Ipp64f* pSrc, Ipp64f* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_64fc,( const Ipp64fc* pSrc, Ipp64fc* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_32s,( const Ipp32s* pSrc, Ipp32s* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_32sc,( const Ipp32sc* pSrc, Ipp32sc* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_64s,( const Ipp64s* pSrc, Ipp64s* pDst, int len ))
IPPAPI(IppStatus, px_ippsCopy_64sc,( const Ipp64sc* pSrc, Ipp64sc* pDst, int len ))
 

Make sure you include ipp.h before you include your custom ipp_generic.h file, so all macro and data type definitions have been taken care of before you declare your generic functions.

Of course, you must also be sure to include the appropriate generic library in the list of libraries that your application will link against. The "USE_IPP" feature that does this automatically for you in Microsoft* Visual Studio* WILL NOT do this for you!

The ZIP file attached to this KB article is an example of how you can setup your ipp_generic.h file automatically using a C macro redifinition. The ZIP file also includes a simple test application.

Determining What Level of SIMD Your Processor Supports

To determine if your processor will be supported by the standard Intel IPP 7.0 library you can use the following test:

Ipp64u u64FeaturesMask = ippCPUID_GETINFO_A ;
Ipp32u u32CpuidInfoRegs[] = { 1, 0, 0, 0 } ;
IppStatus ipp_status ;

if( ipp_status = ippGetCpuFeatures( &u64FeaturesMask, u32CpuidInfoRegs ) )
  /* handle error condition returned by status */ ;

ipp_cpuid = u64FeaturesMask & 0x1ff ;

The contents of ipp_cpuid can be compared against the "CPU Features Mask" enumerations to determine which level of SIMD instructions are supported (see the sample code earlier in this article). A complete table of "CPU Features Mask" enumerations is provided here:

http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/ippxe/ipp_manual_lnx/hh_goto.htm#IPPS/ipps_ch3/functn_ippGetCpuFeatures.htm

The definition of the "CPU Features Mask" is located inside the ippdefs.h header file.

This is not the only method available to determine the SIMD instructions supported by your runtime processor, there are other methods, such as your compiler's cpuid intrinsic; this is just one example.

Hand-tuned optimizations designed to maximize performance of the Intel IPP library on Intel Atom processors were added beginning with v6.0 of the Intel IPP library. For maximum performance on Intel Atom processors, we recommend that you upgrade to version 7.0 of the Intel IPP library.

Both static and dynamic/shared libraries in v7.0 of the Intel IPP library include Intel Atom processor optimizations. Applications linked with versions 7.0 of the Intel IPP library will be dispatched to the "s8" optimized library for IA-32 and the "n8" library for Intel® 64 whenever your application executes on an Intel Atom processor.

For more information regarding dispatching please see Understanding CPU Dispatching in the Intel® IPP Library or check the Intel IPP Getting_Started.htm and userguide_*.pdf files in the Intel IPP documentation.

In the v6.x Intel IPP library, only the dynamic/shared libraries contain Intel Atom processor optimizations; there are no Intel Atom processor optimizations in the v6.x dispatched static libraries. However, the v6.x dispatched static libraries will safely run on an Intel Atom processor by dispatching to the v8/u8 libraries optimized for the Merom microarchitecture (Intel Core 2 processor), which is also designed for use with the same Intel Supplemental SSE3 SIMD instruction set (SSSE3) that Intel Atom processors support. A separate non-dispatched static Intel IPP library for Linux* is available on the IA-32 platform (and as part of the Intel Atom SDK).

The following list of functions have been hand-optimized for the Intel Atom processor for the version of the Intel IPP library listed at the beginning of this article.

Note: every Intel IPP library primitive is available for use with the Intel Atom processor, this list simply shows those functions which have been specially hand-tuned for the Intel Atom processor; hand-tuning is not required to achieve optimum performance for all IPP functions. If you have some specific Intel IPP functions that are not listed in the following table, and would like to see them added to the priority list for Atom optimization, please create a thread on the IPP forum stating which functions you would like to see added to the Atom optimization priority list.

ippsAddProduct_32f
ippsAddProduct_32fc
ippsAddProduct_32s_Sfs
ippsAddProduct_64f
ippsAddProduct_64fc
ippsAdd_32f    
ippsAdd_32fc   
ippsAdd_64f    
ippsAdd_64fc
ippsAdd_32f_I
ippsAdd_32fc_I
ippsAdd_32s_Sfs
ippsConvert_16s32f
ippsConvert_16u32f
ippsConvert_32f16s_Sfs
ippsConvert_32f16u_Sfs
ippsConvert_32f32s_Sfs
ippsConvert_32f8s_Sfs
ippsConvert_32f8u_Sfs
ippsConvert_32s32f
ippsConvert_32s64f
ippsConvert_64f32s_Sfs
ippsConvert_8s32f
ippsConvert_8u32f
ippsCopy_16s
ippsCopy_64s
ippsDFTFwd_CToC_32fc
ippsDFTFwd_CToC_64fc
ippsDiv_16sc_Sfs
ippsDiv_16s_Sfs
ippsDiv_16u_Sfs
ippsDiv_32f
ippsDiv_32fc
ippsDiv_32s16s_Sfs
ippsDiv_32s_Sfs
ippsDiv_64f
ippsDiv_64fc
ippsDotProd_32f32fc64fc
ippsDotProd_32f64f
ippsDotProd_32fc64fc
ippsDotProd_64f
ippsDotProd_64f64fc
ippsDotProd_64fc
ippsFFTFwd_CToC_32fc
ippsFFTFwd_CToC_64fc
ippsFilterMedian_32f
ippsFilterMedian_32s
ippsFilterMedian_64f
ippsFIR32f_16s_Sfs
ippsFIR64f_16s_Sfs
ippsFIR64f_32s_Sfs
ippsFIR_32f
ippsFIR_64f
ippsJoin_32f16s_D2L
ippsLShiftC_32s_I
ippsMax_32s
ippsMean_32f
ippsMin_32s
ippsMul_32f       
ippsMul_32fc      
ippsMul_64f       
ippsMul_64fc
ippsMul_32f_I
ippsMulC_32f
ippsMulC_32f_I
ippsNorm_L2_32f
ippsNormDiff_L2_32f
ippsRShiftC_32s_I
ippsSampleUp_32f
ippsScale_32f_I
ippsSqr_32f
ippsSqr_32f_I
ippsSqr_32fc
ippsSqr_64f
ippsSqr_64fc
ippsSqrt_16s_Sfs
ippsSqrt_16u_Sfs
ippsSqrt_32f
ippsSqrt_32f_I
ippsSqrt_32fc
ippsSqrt_64f
ippsSqrt_64fc
ippsSub_32s_Sfs
ippsSub_32f       
ippsSub_32f_I
ippsSub_32fc      
ippsSub_64f       
ippsSub_64fc      
ippsSum_32f
ippsSum_32f
ippsThreshold_LTVal_32f_I

ippsAdaptiveCodebookSearch_RTA_32f
ippsSBADPCMEncode_G722_16s
ippsSBADPCMDecode_G722_16s
ippsDCTFwd_G7221_16s
ippsDCTInv_G7221_16s
ippsDecomposeDCTToMLT_G7221_16s
ippsDecomposeMLTToDCT_G7221_16s
ippsEnvelopFrequency_G7291_16s
ippsFilterHighpass_G7291_16s
ippsFilterLowpass_G7291_16s
ippsFIRSubbandLow_EC_32sc_Sfs
ippsFIRSubbandLowCoeffUpdate_EC_32sc_I
ippsFixedCodebookSearch_RTA_32f
ippsFixedCodebookSearchRandom_RTA_32f
ippsLSPToLPC_RTA_32f
ippsLSPQuant_RTA_32f
ippsMDCTFwd_G7291_16s
ippsMDCTPostProcess_G7291_16s
ippsQMFDecode_G722_16s
ippsQMFDecode_G7291_16s
ippsQMFEncode_G722_16s
ippsQMFEncode_G7291_16s
ippsSubbandAnalysis_16s32sc_Sfs
ippsSubbandController_EC_32f
ippsSubbandControllerUpdate_EC_32f
ippsSubbandSynthesis_32sc16s_Sfs
ippsTiltCompensation_G7291_16s
ippsToeplizMatrix_G729_32f
ippsToneDetect_EC_32f

ippsCRC32_8u
ippsEncodeRLE_BZ2_8u
ippsReduceDictionary_8u_I
ippsVLCCountBits_16s32s
ippsVLCDecodeOne_1u16s
ippsVLCDecodeUTupleBlock_1u16s
ippsVLCDecodeUTupleOne_1u16s
ippsVLCEncodeInit_32s

ippsMDCTInvWindow_MP3_32s
ippsPow43Scale_16s32s_Sf
ippsPow43_16s32f
ippsPredictCoef_SBR_C_32fc_D2L
ippsSynthesisDownFilter_SBR_CToR_32fc32f_D2L
ippsSynthesisDownFilter_SBR_RToR_32f_D2L
ippsSynthesisFilter_PQMF_MP3_32f
ippsSynthesisFilter_SBR_CToR_32fc32f_D2L
ippsSynthesisFilter_SBR_RToR_32f_D2L
ippsVLCDecodeEscBlock_AAC_1u16s
ippsVLCDecodeEscBlock_MP3_1u16s
ippsVLCDecodeUTupleEscBlock_AAC_1u16s
ippsVLCDecodeUTupleEscBlock_MP3_1u16s

ippiAdd_16s_C1IRSfs
ippiConvert_16u32f_C1R 
ippiConvert_16u8u_C3R 
ippiConvert_8u16s_C1R
ippiConvert_8u16u_C1R 
ippiCopyReplicateBorder_16s_C1R
ippiCopy_8u_C1R 
ippiCopy_8u_C3R 
ippiCopy_8u_C4R 
ippiDilate_32f_AC4R 
ippiDilate_32f_C1R 
ippiDilate_32f_C3R 
ippiDiv_16s_AC4RSfs 
ippiDiv_16s_C1RSfs 
ippiDiv_16s_C3RSfs 
ippiDiv_16s_C4RSfs 
ippiDiv_16u_AC4RSfs 
ippiDiv_16u_C1RSfs 
ippiDiv_16u_C3RSfs 
ippiDiv_16u_C4RSfs 
ippiDiv_32f_AC4R 
ippiDiv_32f_C1R 
ippiDiv_32f_C3R 
ippiDiv_32f_C4R 
ippiErode_32f_AC4R 
ippiErode_32f_C1R 
ippiErode_32f_C3R 
ippiFilter32f_8u_AC4R
ippiFilter32f_8u_C1R 
ippiFilter32f_8u_C3R 
ippiFilter32f_8u_C4R 
ippiFilterGauss_16s_AC4R 
ippiFilterGauss_16s_C1R 
ippiFilterGauss_16s_C3R 
ippiFilterGauss_16s_C4R 
ippiFilterGauss_32f_AC4R 
ippiFilterGauss_32f_C1R 
ippiFilterGauss_32f_C3R 
ippiFilterGauss_32f_C4R 
ippiFilter_16s_AC4R 
ippiFilter_16s_C1R 
ippiFilter_16s_C3R 
ippiFilter_16s_C4R 
ippiFilter_16u_AC4R 
ippiFilter_16u_C1R 
ippiFilter_16u_C3R 
ippiFilter_16u_C4R 
ippiFilter_8u_AC4R 
ippiFilter_8u_C1R 
ippiFilter_8u_C3R 
ippiFilter_8u_C4R 
ippiGetPerspectiveQuad
ippiMirror_16u_C1IR
ippiMirror_16u_C4R 
ippiMirror_32s_C4R 
ippiMirror_8u_C4R 
ippiMul_32f_AC4R 
ippiMul_32f_C1R 
ippiMul_32f_C3R 
ippiMul_32f_C4R 
ippiSet_16u_C3R 
ippiSet_16u_C4R 
ippiSet_32f_C1R 
ippiSet_32f_C3R 
ippiSet_8u_C3R 
ippiSet_8u_C4R 
ippiSqrt_16s_AC4RSfs 
ippiSqrt_16s_C1RSfs 
ippiSqrt_16s_C3RSfs 
ippiSqrt_16u_AC4RSfs 
ippiSqrt_16u_C1RSfs 
ippiSqrt_16u_C3RSfs 
ippiSqrt_32f_AC4R 
ippiSqrt_32f_C1R 
ippiSqrt_32f_C3R 
ippiSqr_32f_AC4R 
ippiSqr_32f_C1R 
ippiSqr_32f_C3R 
ippiSqr_32f_C4R 
ippiSub_16s_C1IRSfs

ippiBGR555ToYCbCr420_16u8u_C3P3R
ippiBGR555ToYCbCr422_16u8u_C3C2R
ippiBGR555ToYCbCr422_16u8u_C3P3R
ippiBGR555ToYCrCb420_16u8u_C3P3R
ippiBGR555ToYUV420_16u8u_C3P3R
ippiBGR565ToYCbCr411_16u8u_C3P3R
ippiBGR565ToYCbCr420_16u8u_C3P3R
ippiBGR565ToYCbCr422_16u8u_C3C2R
ippiBGR565ToYCbCr422_16u8u_C3P3R
ippiBGR565ToYCrCb420_16u8u_C3P3R
ippiBGR565ToYUV420_16u8u_C3P3R
ippiBGRToCbYCr422_8u_AC4C2R
ippiBGRToHLS_8u_AC4P4R
ippiBGRToHLS_8u_AP4C4R
ippiBGRToHLS_8u_AP4R
ippiBGRToHLS_8u_C3P3R
ippiBGRToHLS_8u_P3C3R
ippiBGRToHLS_8u_P3R
ippiBGRToYCbCr422_8u_AC4C2R
ippiBGRToYCbCr422_8u_AC4P3R
ippiBGRToYCbCr422_8u_C3C2R
ippiBGRToYCbCr422_8u_C3P3R
ippiCbYCr422ToBGR_8u_C2C4R
ippiHLSToBGR_8u_AC4P4R
ippiHLSToBGR_8u_AP4C4R
ippiHLSToBGR_8u_AP4R
ippiHLSToBGR_8u_C3P3R
ippiHLSToBGR_8u_P3C3R
ippiHLSToBGR_8u_P3R
ippiRGB565ToYUV422_16u8u_C3P3R
ippiRGBToCbYCr422Gamma_8u_C3C2R
ippiRGBToCbYCr422_8u_C3C2R
ippiRGBToYCbCr422_8u_C3C2R
ippiRGBToYCbCr422_8u_C3P3R
ippiRGBToYCbCr_8u_P3R
ippiRGBToYCrCb422_8u_P3C2R
ippiRGBToYUV420_8u_P3
ippiRGBToYUV420_8u_P3R
ippiRGBToYUV422_8u_C3C2R
ippiRGBToYUV422_8u_C3P3
ippiRGBToYUV422_8u_C3P3R
ippiRGBToYUV422_8u_P3
ippiRGBToYUV422_8u_P3R
ippiRGBToYUV_8u_AC4R
ippiRGBToYUV_8u_C3R
ippiRGBToYUV_8u_P3R
ippiYCbCr422To420_Interlace_8u_P3R
ippiYCbCr422ToBGR_8u_C2C3R
ippiYCbCr422ToBGR_8u_C2P3R
ippiYCbCrToRGB_8u_P3R
ippiYUV422ToRGB_8u_P3C3
ippiYUV422ToRGB_8u_P3C3R
ippiYUVToRGB_8u_P3C3R

ippiReconstructLumaIntra4x4_H264High_32s16u_IP1R
ippiFilterDeblockingLumaVerEdge_H264_16u_C1IR
ippiFilterDeblockingLumaHorEdge_H264_16u_C1IR

ippsFindCAny_8u
ippmInvert_m_32f
ippmMul_tm_32f

Functions not listed above are either hand-optimized for the Merom microarchitecture (SSSE3) or for prior SIMD instruction sets that are compatible with the Intel Atom processor (such as SSE2). In addition, the entire Intel Atom optimized library is compiler-optimized for the Intel Atom processor using the Intel Compiler xSSE3_ATOM switch (enable Atom optimizations) in order to take advantage of features unique to the Intel Atom processor.

Please see Optimized for the Intel® Atom™ Processor with Intel's Compiler for more information and check out the Intel Parallel Studio web site where you can learn more about the tools available to develop, debug, and tune your multi-threaded applications.

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

The table below reflects the Intel AVX support provided in the Intel IPP 7.0.2 library release.

Intel AVX optimized code is available in both the 32-bit and 64-bit editions of the 7.0 library.

There is very limited support for Intel AVX in the 6.1 library; if you plan to use Intel IPP on an Intel AVX platform you should upgrade to the 7.0 version of the Intel IPP library.

Intel® AVX (Intel® Advanced Vector Extensions) is a 256-bit instruction set extension to SSE designed to provide even higher performance for applications that are floating-point intensive. Intel AVX adds new functionality to the the existing Intel SIMD instruction set (based on SSE) and includes a more compact SIMD encoding format. A large number (200+) of Intel SSEx instructions have been "upgraded" in AVX to take advantage of features like a distinct destination operand and flexible memory alignment. Approximately 100 of the legacy 128-bit Intel SSEx instructions have been promoted to process 256-bit vector data. In addition, approximately 100 new data processing and arithmetic operations, not present in the legacy Intel SSEx SIMD instruction set, have been added.

The primary benefits of Intel AVX are:

• Support for wider vector data (up to 256-bit).
• Efficient instruction encoding scheme that supports 3 and 4 operand instruction syntaxes.
• Flexible programming environment, ranging from branch handling to relaxed memory alignment requirements.
• New data manipulation and arithmetic compute primitives, including broadcast, permute, fused-multiply-add, etc.
  
  

ippGetCpuFeatures() reports information regarding the SIMD features available to your processor. Alternatively, ippGetCpuType() detects the processor type in your system. A return value of ippCpuAVX means your processor supports the Intel AVX instruction set. These functions are declared in ippcore.h.

Mask the value returned by ippGetCpuFeatures() with ippCPUID_AVX (0x0100) to determine if the Intel AVX SIMD instructions are supported by your processor (ippGetCpuFeatures() & ippCPUID_AVX is TRUE). To determine if your operating system also supports the Intel AVX instructions (saves the extended SIMD registers), mask the returned value from ippGetCpuFeatures() with ippAVX_ENABLEDBYOS (0x0200). Both conditions (i.e., CPU and OS support) must be met before your application can utilize the Intel AVX SIMD instructions.

The Intel IPP library has been optimized for a variety of SIMD instruction sets. Automatic "dispatching" detects the SIMD instruction set that is available on the running processor and selects the optimal SIMD instructions for that processor. Please review Understanding CPU Dispatching in the Intel® IPP Library for more information regarding dispatching.

Intel AVX optimization in the Intel IPP library consists of "hand-optimized" and "compiler-tuned" functions – code that has been directly optimized for the Intel AVX instruction set. Given the large number of primitives in the Intel IPP library, it is impossible to directly optimize every Intel IPP function for the large set of new instructions represented by the Intel AVX instruction set within the period of a single product release or update (processor-specific optimizations may also take into consideration cache size and number of cores/threads). Therefore, the functions in the table below represent those that either receive the greatest benefit from the new Intel AVX instructions or are the most widely used by Intel IPP customers.

If you have some specific Intel IPP functions that are not listed in the following table, and would like to see them added to the priority list for future AVX optimization, please create a thread on the IPP forum stating which functions you would like to see added to the AVX optimization priority list.

Functions directly optimized for Intel AVX are added to the table below as they become available with each new release or update of the library.

The following conventions are used in the table below to allow multiple similar functions to be denoted on a single line:

• {x} - Braces enclose a required (function name) element.
• [x] - Square brackets enclose an optional (function name) element.
• | - A vertical line indicates an exclusive choice within a set of optional or required elements.
• {x|y|z} - Example of three mutually exclusive choices within a required element in the function name.
• [x|y|z] - Example of three mutually exclusive choices within an optional element in the function name.

ippsAbs_{16s|32s|32f|64f}[_I] 
ippsAdd_{32f|32fc|64f|64fc}[_I] 
ippsAddC_{32f|64f}[_I] 
ippsAddProductC_32f 
ippsAddProduct_{32fc|64f|64fc} 
ippsAutoCorr_{32f|64f}
ippsConv_32f 
ippsConvert_{8s|8u|16s|16u|32s|64f}32f 
ippsConvert_{32s|32f}64f 
ippsConvert_32f{8s|8u|16s|16u}_Sfs 
ippsConvert_64f32s_Sfs 
ippsCopy_{16s|32s|32f|64f} 
ippsCrossCorr_{32f|64f} 
ippsDFTFwd_CToC_{32f|32fc|64f|64fc} 
ippsDFTFwd_RTo{CCS|Pack|Perm}_{32f|64f} 
ippsDFTInv_CCSToR_{32f|64f} 
ippsDFTInv_CToC_{32f|32fc|64f|64fc} 
ippsDFTInv_{Pack|Perm}ToR_{32f|64f} 
ippsDFTOutOrd{Fwd|Inv}_CToC_{32fc|64fc} 
ippsDiv[C]_32f[_I] 
ippsDotProd_32f64f 
ippsFFTFwd_CToC_{32f|32fc|64f|64fc}[_I] 
ippsFFTFwd_RTo{CCS|Pack|Perm}_{32f|64f}[_I] 
ippsFFTInv_CCSToR_{32f|64f}[_I] 
ippsFFTInv_CToC_{32f|32fc|64f|64fc}[_I] 
ippsFFTInv_{Pack|Perm}ToR_{32f|64f}[_I] 
ippsFIR64f_32f[_I] 
ippsFIR64fc_32fc[_I] 
ippsFIRLMS_32f 
ippsFIR_{32f|32fc|64f|64fc}[_I] 
ippsIIR32fc_16sc_[I]Sfs 
ippsIIR64fc_32fc[_I] 
ippsIIR_32f[_I] 
ippsLShiftC_16s_I 
ippsMagnitude_16sc_Sfs 
ipps{Min|Max}Indx_{32f|64f} 
ippsMul_32fc[_I] 
ippsMul[C]_{32f|32fc|64f|64fc}[_I] 
ippsMulC_64f64s_ISfs 
ipps{Not|Or}_8u 
ippsPhase_{16s|16sc|32sc}_Sfs 
ippsPowerSpectr_{32f|32fc} 
ippsRShiftC_16u_I 
ippsSet_{8u|16s|32s} 
ippsSqr_{8u|16s|16u|16sc}_[I]Sfs 
ippsSqr_{32f|32fc|64f|64fc}[_I] 
ippsSqrt_32f[_I] 
ippsSub_{32f|32fc|64f|64fc}[_I] 
ippsSubC_{32f|32fc|64f|64fc}[_I] 
ippsSubCRev_{32f|32fc|64f|64fc}[_I] 
ippsSum_{32f|64f} 
ippsThreshold_{32f|GT_32f|LT_32f}_[_I] 
ippsThreshold_{GT|LT}Abs_{32f|64f}[_I] 
ippsThreshold_GTVal_32f[_I] 
ippsWinBartlett_{32f|32fc|64f|64fc}[_I] 
ippsWinBlackman_{32f|64f|64fc}[_I] 
ippsWinBlackmanOpt_{32f|64f|64fc}[_I] 
ippsWinBlackmanStd_{32f|64f|64fc}[_I] 
ippsWinKaiser_{32f|64f|64fc}[_I] 
ippsZero_{8u|16s|32f}

ippgDFTFwd_CToC_8_64fc ippgDFTFwd_CToC_12_64fc 
ippgDFTFwd_CToC_16_{32fc|64fc}
ippgDFTFwd_CToC_20_64fc
ippgDFTFwd_CToC_24_64fc
ippgDFTFwd_CToC_28_64fc 
ippgDFTFwd_CToC_32_{32fc|64fc}
ippgDFTFwd_CToC_36_64fc
ippgDFTFwd_CToC_40_64fc
ippgDFTFwd_CToC_44_64fc 
ippgDFTFwd_CToC_48_{32fc|64fc}
ippgDFTFwd_CToC_52_64fc 
ippgDFTFwd_CToC_56_64fc 
ippgDFTFwd_CToC_60_64fc 
ippgDFTFwd_CToC_64_{32fc|64fc} 
ippgDFTInv_CToC_8_64fc 
ippgDFTInv_CToC_12_64fc 
ippgDFTInv_CToC_16_{32fc|64fc} 
ippgDFTInv_CToC_20_64fc 
ippgDFTInv_CToC_24_64fc 
ippgDFTInv_CToC_28_64fc 
ippgDFTInv_CToC_32_{32fc|64fc} 
ippgDFTInv_CToC_36_64fc 
ippgDFTInv_CToC_40_64fc 
ippgDFTInv_CToC_44_64fc 
ippgDFTInv_CToC_48_{32fc|64fc} 
ippgDFTInv_CToC_52_64fc 
ippgDFTInv_CToC_56_64fc 
ippgDFTInv_CToC_60_64fc 
ippgDFTInv_CToC_64_{32fc|64fc}

iippsDeinterleave_32f

ippsAdaptiveCodebookSearch_RTA_32f
ippsFixedCodebookSearch_RTA_32f
ippsFixedCodebookSearchRandom_RTA_32f
ippsHighPassFilter_RTA_32f
ippsLSPQuant_RTA_32f
ippsLSPToLPC_RTA_32f
ippsPostFilter_RTA_32f_I
ippsQMFDecode_RTA_32f
ippsSynthesisFilter_G729_32f

ippiRGBToHLS_8u_AC4R
ippiRGBToHLS_8u_C3R

ipprCastEye_32f
ipprCastShadowSO_32f
ipprDot_32f_P3C1M
ipprHitPoint3DEpsM0_32f_M
ipprHitPoint3DEpsS0_32f_M
ipprMul_32f_C1P3IM

ippiEigenValsVecs_[8u]32f_C1R 
ippiFilterGaussBorder_32f_C1R 
ippiMinEigenVal_[8u]32f_C1R 
ippiNorm_Inf_{8u|8s|16u|32f}_C{1|3C}MR 
ippiNorm_L1_{8u|8s|16u|32f}_C{1|3C}MR 
ippiNorm_L2_{8u|8s|16u|32f}_C{1|3C}MR 
ippiNormRel_L2_32f_C3CMR 
ippiUpdateMotionHistory_[8u|16u]32f_C1IR

ippiAddC_32f_C1[I]R 
ippiConvert_32f* 
ippiCopy_16s* 
ippiCopy_8u* 
ippiConvFull_32f_{AC4|C1|C3}R 
ippiConvValid_32f_{AC4|C1|C3}R 
ippiCrossCorrFull_NormLevel_16u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_NormLevel_32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_NormLevel_64f_C1R 
ippiCrossCorrFull_NormLevel_8s32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_NormLevel_8u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_NormLevel_8u_{AC4|C1|C3|C4}RSfs 
ippiCrossCorrFull_Norm_16u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_Norm_32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_Norm_8s32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_Norm_8u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrFull_Norm_8u_{AC4|C1|C3|C4}RSfs 
ippiCrossCorrSame_NormLevel_16u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_NormLevel_32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_NormLevel_8s32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_NormLevel_8u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_NormLevel_8u_{AC4|C1|C3|C4}RSfs 
ippiCrossCorrSame_Norm_16u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_Norm_32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_Norm_8s32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_Norm_8u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrSame_Norm_8u_{AC4|C1|C3|C4}RSfs 
ippiCrossCorrValid_{8u32f|8s32f|16u32f|32f}_C1R 
ippiCrossCorrValid_NormLevel_16u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_NormLevel_32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_NormLevel_64f_C1R 
ippiCrossCorrValid_NormLevel_8s32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_NormLevel_8u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_NormLevel_8u_{AC4|C1|C3|C4}RSfs 
ippiCrossCorrValid_Norm_16u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_Norm_32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_Norm_8s32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_Norm_8u32f_{AC4|C1|C3|C4}R 
ippiCrossCorrValid_Norm_8u_{AC4|C1|C3|C4}RSfs 
ippiDCT8x8FwdLS_8u16s_C1R 
ippiDCT8x8Fwd_16s_C1[I|R] 
ippiDCT8x8Fwd_32f_C1[I] 
ippiDCT8x8Fwd_8u16s_C1R 
ippiDCT8x8InvLSClip_16s8u_C1R 
ippiDCT8x8Inv_16s8u_C1R 
ippiDCT8x8Inv_16s_C1[I|R] 
ippiDCT8x8Inv_2x2_16s_C1[I] 
ippiDCT8x8Inv_32f_C1[I] 
ippiDCT8x8Inv_4x4_16s_C1[I] 
ippiDCT8x8Inv_A10_16s_C1[I] 
ippiDCT8x8To2x2Inv_16s_C1[I] 
ippiDCT8x8To4x4Inv_16s_C1[I] 
ippiDFTFwd_CToC_32fc_C1[I]R 
ippiDFTFwd_RToPack_32f_{AC4|C1|C3|C4}[I]R 
ippiDFTFwd_RToPack_8u32s_{AC4|C1|C3|C4}RSfs 
ippiDFTInv_CToC_32fc_C1[I]R 
ippiDFTInv_PackToR_32f_{AC4|C1|C3|C4}[I]R 
ippiDFTInv_PackToR_32s8u_{AC4|C1|C3|C4}RSfs 
ippiDilate3x3_32f_C1[I]R 
ippiDilate3x3_64f_C1R 
ippiDivC_32f_C1[I]R 
ippiDiv_32f_{C1|C3}[I]R 
ippiDotProd_32f64f_{C1|C3}R 
ippiErode3x3_64f_C1R 
ippiFFTFwd_CToC_32fc_C1[I]R 
ippiFFTFwd_RToPack_32f_{AC4|C1|C3|C4}[I]R 
ippiFFTFwd_RToPack_8u32s_{AC4|C1|C3|C4}RSfs 
ippiFFTInv_CToC_32fc_C1[I]R 
ippiFFTInv_PackToR_32f_{AC4|C1|C3|C4}[I]R 
ippiFFTInv_PackToR_32s8u_{AC4|C1|C3|C4}RSfs 
ippiFilter_32f_{C1|C3|C4}R 
ippiFilter_32f_AC4R 
ippiFilter_64f_{C1|C3}R 
ippiFilter32f_{8s|8u|16s|16u|32s}_C{1|3|4}R 
ippiFilter32f_{8u|16s|16u}_AC4R 
ippiFilter32f_{8s|8u}16s_C{1|3|4}R 
ippiFilterBox_8u_{C1|C3}R 
ippiFilterBox_32f_{C1|C4|AC4}R 
ippiFilterColumn32f_{8u|16s|16u}_{C1|C3|C4|AC4}R 
ippiFilterColumn_32f_{C1|C3|C4|AC4}R 
ippiFilterGauss_32f_{C1|C3}R 
ippiFilterHipass_32f_{C1|C3|C4|AC4}R 
ippiFilterLaplace_32f_{C1|C3|C4|AC4}R 
ippiFilterLowpass_32f_{C1|C3|AC4}R 
ippiFilterMax_32f_{C1|C3|C4|AC4}R 
ippiFilterMedian_32f_C1R 
ippiFilterMin_32f_{C1|C3|C4|AC4}R 
ippiFilterRow_32f_{C1|C3|C4|AC4}R 
ippiFilterRow32f_{8u|16s|16u}_{C1|C3|C4|AC4}R 
ippiFilterSobelHoriz_32f_{C1|C3}R 
ippiFilterSobelVert_32f_{C1|C3}R 
ippiMean_32f_{C1|C3}R 
ippiMulC_32f_C1[I]R 
ippiMul_32f_{C1|C3|C4}[I]R 
ippiResizeSqrPixel_{32f|64f}_{C1|C3|C4|AC4}R 
ippiResizeSqrPixel_{32f|64f}_{P3|P4}R 
ippiSqrDistanceFull_Norm_16u32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceFull_Norm_32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceFull_Norm_8s32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceFull_Norm_8u32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceFull_Norm_8u_{AC4|C1|C3|C4}RSfs 
ippiSqrDistanceSame_Norm_16u32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceSame_Norm_32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceSame_Norm_8s32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceSame_Norm_8u32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceSame_Norm_8u_{AC4|C1|C3|C4}RSfs 
ippiSqrDistanceValid_Norm_16u32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceValid_Norm_32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceValid_Norm_8s32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceValid_Norm_8u32f_{AC4|C1|C3|C4}R 
ippiSqrDistanceValid_Norm_8u_{AC4|C1|C3|C4}RSfs 
ippiSqrt_32f_C1R 
ippiSqrt_32f_C3IR 
ippiSubC_32f_C1[I]R 
ippiSub_32f_{C1|C3|C4}[I]R 
ippiSum_32f_C{1|3}R 
ippiTranspose_32f_C1R

ippiPCTFwd_JPEGXR_32f_C1IR 
ippiPCTFwd16x16_JPEGXR_32f_C1IR 
ippiPCTFwd8x16_JPEGXR_32f_C1IR 
ippiPCTFwd8x8_JPEGXR_32f_C1IR 
ippiPCTInv_JPEGXR_32f_C1IR_128 
ippiPCTInv16x16_JPEGXR_32f_C1IR 
ippiPCTInv8x16_JPEGXR_32f_C1IR 
ippiPCTInv8x8_JPEGXR_32f_C1IR

Those functions that have not been directly optimized for AVX (i.e., functions that do not appear in the table) have been compiled using the Intel Compiler "xG" switch (enable AVX optimization). Additional performance improvements are achieved by adherence to an AVX ABI (application binary interface) feature that inserts the special AVX "vzeroupper" instruction after any function with AVX code to eliminate any AVX to SSE transition penalties.

For those functions that are not directly optimized for AVX, the g9/e9 library utilizes optimizations from prior compatible SSE optimizations, such as those tuned for the p8/y8 libraries and preceding SIMD optimizations (e.g., SSE4.x, AES-NI and SSE2/3). Thus, functions not listed above will include the highest level of directly optimized code based on the AES-NI, SSE4.x, SSSE3, SSE3 and SSE2 SIMD instruction sets, wherever applicable.

For more information about the g9/e9 optimization layer and Intel AVX in the Intel IPP library, please refer to the Intel Integrated Performance Primitives for Windows* OS on Intel® 64 Architecture 'User's Guide'.

Review How to Compile for Intel® AVX for more information and check out the Intel Parallel Studio web site where you can learn more about the tools available to develop, debug, and tune your multi-threaded applications.

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

20 sep 2011 – article update – the ZIP file has been updated to include a missing DLL and it also now contains both AWK and GAWK executables. If you already have the necessary UNIX utilities on your Windows system (e.g., Cygwin or MinGW) you may not need the contents of the ZIP file. In any case please download the "ipp-fn-survey.awk" script file, it is required regardless of the UNIX utilities you use to run the script! On Windows, this AWK script has only been verified against the old GnuWin32 utils provided here. The GnuWin32 utils distributed in the attached ZIP file can be found here: http://gnuwin32.sourceforge.net/packages.html.

In the interest of developing a list of "most frequently used" functions by customers of the Intel IPP library, we have created a simple AWK script that can be used on either a Windows or Linux system to extract the names of the Intel IPP functions used in your application, without having to reveal any of your application source.

The number of Intel IPP functions present in the library is quite large; as a result, optimizing the entire library for new SIMD architectures must be performed in phases. In general, we would like to optimize first those functions that are most popular and relevant to our customers, in order to insure that your applications receive the maximum benefit as new SIMD architectures and/or extensions to those architectures are introduced.

Attached to this KB article are two files:

• ipp-fn-survey.awk
• GnuWin32-utils.zip

The AWK script scans C/C++ source code to identify any function that conforms to the standard naming scheme used by the Intel IPP library. This AWK script is provided in source format, so you can inspect the script to determine exactly what it does.

In essence, this script:

1. removes /* */ and // style comments to avoid false detects within comments
2. removes " " string constants to avoid false detects within strings
3. searches for and lists the names of all Intel IPP "core" functions
4. searches for and lists the names of all Intel IPP "administrative" functions

The script is not perfect and may miss a few Intel IPP functions. Please see the comments inside the AWK script for more details on known or suspected issues.

If the source tree you scan includes the IPP header files (ippac.h, ippcc.h, ippch.h, etc.) be sure to exclude those files from the search; otherwise, you will include every IPP function listed in those headers, even if you are not using them in your source code.

Basic Operation on Windows:

To run this script on a Windows machine you will need a copy of the GnuWin32 GAWK application (or a compatible AWK). In order to build a concise and sorted list of the Intel IPP functions used within your application it is also helpful to utilize the UNIX-compatible find, sort and uniq functions. All of these functions are provided in the GnuWin32-utils.zip attachment to this KB article. With the GnuWin32 applications installed on your Windows system, use the following command line:

>find src_dir -regex ".+\.[ch]p*" -exec gawk -f ipp-fn-survey.awk {} ; | sort | uniq >ipp-survey.txt

where "src_dir" is the root of the directory you wish to scan source for names of IPP functions -- simplest way to do this is to copy the AWK file and the contents of the ZIP file (GnuWin32-utils-zip) to "src_dir" and type:

>find . -regex ".+\.[ch]p*" -exec gawk -f ipp-fn-survey.awk {} ; | sort | uniq >ipp-survey.txt

Note: on a Windows system "find" needs to be a UNIX compatible version of find, not the Microsoft find. To avoid name conflicts with the Microsoft find.exe you might need to rename the GnuWin32 "find.exe" file to "uxfind.exe" and then run the samples above by referencing "uxfind" rather than "find" at the beginning of each script execution command.

If you used the command line above, the results of the scan will be found in the file named "ipp-survey.txt" in the starting directory.

Basic Operation on Linux:

To run this script on a Linux machine you will need the standard Gnu AWK, find, sort, uniq and xargs utilities that are normally present on your Linux system. Use the following command line:

$find src_dir -iregex ".+\.[ch]p*" | xargs ./ipp-fn-survey.awk | sort | uniq >ipp-survey.txt

where "src_dir" is the root of the directory you wish to scan source for names of IPP functions -- simplest way to do this is to copy this AWK file to the "src_dir" and type:

$find . -regextype posix-awk -iregex ".+\.[ch]p*" | xargs ./ipp-fn-survey.awk | sort | uniq >ipp-survey.txt

Note: GAWK on some Linux systems may not honor IGNORECASE -- resulting in a few false finds. Also, make sure the "executable" bits are set properly on the AWK script.

If you used the command line above, the results of the scan will be found in the file named "ipp-survey.txt" in the starting directory.

On some Linux systems you may not have gawk but awk installed on your system. The first line of the ipp-fun-survey.awk file references /usr/bin/gawk as the script interpreter. If your system instead only contains /usr/bin/awk you need to change that first line. To determine which application is on your system type "which gawk" at a command prompt. If nothing is returned type "which awk" at the command line. If your system only contains awk, or the application is located someplace other than /usr/bin, you will have to edit the first line of the ipp-fn-survey.awk script.

Terms and Conditions

This script will not reveal any source code or parameter names, only the names of the IPP functions referenced in the source code that it scans.

Note that this script is being provided under the terms and conditions of the Intel IPP EULA. Please insure you agree to those terms before using the script to provide us with a list of the Intel IPP primitives you are using.

If you are able to run this script (or something similar) on your application source code and generate a list of IPP functions that you would like to share with us, please reply to this posting (using the private option, if you prefer) with some information about your company and your application, as well as the list of Intel IPP functions created by the script or an email address you may use to contact you directly. Your input is very valuable for the prioritization of future optimizations within the Intel IPP library.

IMPORTANT! The minimum SIMD instruction levels supported by version 7.0 of the Intel IPP library has changed! Applications built with this version of the library require that processors must support at least the Intel® Streaming SIMD Extensions 2 (Intel® SSE2) instruction set when built for Intel IA-32 processors (ia32) and the Intel® Streaming SIMD Extensions 3 (Intel® SSE3) instruction set when built for Intel® 64 processors (intel64). The non-optimized layers of the library (px on ia32 and mx on intel64) have been removed; the w7 and m7 optimization layers are now the default optimization layers.

The standard distribution of the Intel IPP library contains multiple, functionally-identical, SIMD-specific, optimized libraries (or layers) that are automatically “dispatched” at run-time. The “dispatcher” directs your calls to the appropriate optimized library layer based on SIMD capabilities discovered during library initialization. This is done to maximize each function’s use of the runtime processor's underlying SIMD instructions and other architecture-specific features.

Note: you can build custom processor-specific libraries that do not require the dispatcher, but that is outside the scope of this article. Please read this IPP linkage models article for information on how to build custom versions of the IPP library.

Dispatching selects the Intel IPP optimized library layer that corresponds to the runtime CPU's SIMD instruction set. For example, on a Windows installation, the $(IPPROOT)\..\redist\intel64\ipp directory contains a file named ippiu8-7.0.dll which contains version ‘7.0’ of the optimized image processing libraries for processors that support the Intel SSE3 instructions on 64-bit processors; ‘ippi’ denotes the image processing domain, ‘u8’ denotes the SSSE3 instructions set for 64-bit processors and ‘7.0’ denotes the library’s version number.

In the general case, the “dispatcher” identifies the run-time processor only once, at library initialization time, and sets up a variable internal to the library that directs your calls to the SIMD-specific functions that match the runtime processor. For example, ippsCopy_8u(), has multiple implementations stored in the library, with each version optimized to a specific SIMD instruction set. The u8_ippsCopy_8u() version of ippsCopy_8u() is called by the dispatcher when running on an Intel® Core 2 Duo® processor in 64-bit addressing mode, because u8_ippsCopy_8u() is optimized for the SSSE3 instruction set architecture supported by that processor in 64-bit addressing mode.

Note: IPP architectures generally correspond to SIMD (MMX, SSE, AES, etc.) instructions sets, with some minor variations (see the p8 and y8 optimization layers).

Initializing the IPP Dispatcher

Identifying the runtime processor and initializing the dispatcher should be the first action you take with the Intel IPP library. If you are using the standard dynamic link library this process is handled automatically when the Intel IPP shared library is initialized. If you are using a static library you must perform this step manually. See this article on the ipp*Init*() functions for more information on how to do this.

Because the minimum SIMD instruction set is SSE2 on IA-32 and SSE3 on Intel 64 processors it is recommended that you ALWAYS call the the ippInit() function before making any other calls to the Intel IPP library. This advice applies regardless of whether you are linking against the static or dynamic form of the library (even though the dynamic library will also perform this call).

Calling the ippInit() function with the shared libraries (DLL and SO) will generate an error message to a dialog box or error console if the ippInit() function detects that the runtime CPU is not supported by the Intel IPP library. Calling the ippInit() function in the static versions of the library will not generate a console or dialog message. Both versions of the ippInit() function will return an error code when a non-supported CPU is detected.

It is important that you call the ippInit() function at the beginning of your application to insure that the processor on which your application is running will support the Intel IPP library. If the ippInit() function returns an error code you should close your application gracefully in order to avoid an unexpected termination of your application by an invalid instruction fault because your application is running on an unsupported processor.

The following table lists the SIMD architecture codes supported by version 7.0 of the Intel IPP library.

For non-Intel based processors support, please read Use Intel® IPP on Intel or Compatible AMD* Processors.

If you compare this dispatch table above to the 5.3 thru 6.1 dispatch table you will note that the Intel SSE3 optimization layer (t7) has been removed from the 32-bit edition (ia32) of the library. 32-bit applications built with the 7.0 version of the library that execute on an SSE3 processor will automatically use the Intel SSE2 optimization layer (w7). In most cases, the impact of this change is minor, since the performance difference between the Intel SSE3 (t7) and Intel SSE2 (w7) optimization layers in the Intel IPP library is minimal. Processors that support the Intel SSSE3 instruction set (v8 and s8 optimization layers) are not affected by this change. (Note: this change does not impact applications built using the 64-bit edition of the library, which now uses the Intel SSE3 optimization layer (m7) as its default path.)

P8/Y8 Internal Run-Time Dispatcher

Within the 32-bit p8 and equivalent 64-bit y8 architectures there is an additional "runtime dispatcher," a mini-dispatcher. The Nehalem and Westmere processor microarchitectures add additional SIMD instructions beyond those defined by SSE4.1. The Nehalem processor microarchitecture added SSE4.2 SIMD instructions and the Westmere processor microarchitecture added Inte® AES-NI.

Creating two separate optimization layers within the IPP library for the small set of instructions added by SSE4.2 and AES-NI would be very space inefficient, so they are bundled into the SSE4.1 library (p8/y8) as minor variants to that optimization layer. When you call a function that includes, for example, AES-NI optimizations, an additional jump directs your call to the AES-NI version within the p8/y8 library if your runtime processor supports these instructions. Because the enhancements affect the optimization of only a small number of Intel IPP functions, this additional overhead occurs infrequently and only when your application is executing on a p8/y8 architecture processor that supports these extra instructions.

S8/N8 (Atom) Dispatch

Unlike preceding versions of the library, the 7.0 version of the Intel IPP library does include Atom-optimized variants of the library within all formats (static and dynamic) of the library. For this reason, the Linux distribution of the 7.0 version of the Intel IPP library no longer includes a separate Atom-specific version of the library, since Atom-specific optimizations have been fully merged into all formats of the standard library files.

Please read Intel® Atom™ Processors Support in the Intel® Integrated Performance Primitives (Intel® IPP) Library for more information regarding Atom optimizations in the IPP library.

Processor Architecture Table

The following table was copied from an Intel Compiler Pro options article describing some compiler architecture options. It contains a list of Intel processors showing which processors support which SIMD instructions. For the latest table please refer to the original article; it gets updated on a regular basis. Please note that the behavior of the Intel Compiler SIMD dispatcher described in that article does not apply to the Intel IPP library.

The Intel IPP library dispatching mechanism behaves differently than that found in the Intel Compiler products, and may also behave differently than other Intel library products.

Additional information regarding dispatching and how it relates to non-Intel processors can be found here. How to identify your specific processor is described here. To correlate a processor family name with an Intel CPU brand name, use the following web site: ark.intel.com.

SSE4.2
Intel® Core™ i7 processors
Intel® Core™ i5 processors
Intel® Core™ i3 processors
Intel® Xeon® 55XX series

SSE4.1
Intel® Xeon® 74XX series
Quad-Core Intel® Xeon 54XX, 33XX series
Dual-Core Intel® Xeon 52XX, 31XX series
Intel® Core™ 2 Extreme 9XXX series
Intel® Core™ 2 Quad 9XXX series
Intel® Core™ 2 Duo 8XXX series
Intel® Core™ 2 Duo E7200

SSSE3
Quad-Core Intel® Xeon® 73XX, 53XX, 32XX series
Dual-Core Intel® Xeon® 72XX, 53XX, 51XX, 30XX series
In tel® Core™ 2 Extreme 7XXX, 6XXX series
Intel® Core™ 2 Quad 6XXX series
Intel® Core™ 2 Duo 7XXX (except E7200), 6XXX, 5XXX, 4XXX series
Intel® Core™ 2 Solo 2XXX series
Intel® Pentium® dual-core processor E2XXX, T23XX series

SSE3
Dual-Core Intel® Xeon® 70XX, 71XX, 50XX Series
Dual-Core Intel® Xeon® processor (ULV and LV) 1.66, 2.0, 2.16
Dual-Core Intel® Xeon® 2.8
Intel® Xeon® processors with SSE3 instruction set support
Intel® Core™ Duo
Intel® Core™ Solo
Intel® Pentium® dual-core processor T21XX, T20XX series
Intel® Pentium® processor Extreme Edition
Intel® Pentium® D
Intel® Pentium® 4 processors with SSE3 instruction set support

SSE2
Intel® Xeon® processors
Intel® Pentium® 4 processors
Intel® Pentium® M

IA32
Intel® Pentium® III Processor
Intel® Pentium® II Processor
Intel® Pentium® Processor

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

1. Build system requirement

Software:
•   Intel Parallel Studio 2011 and Microsoft* Visual Studio 2005 and later
•   (optional)  install static ipp library separately from http://software.intel.com/en-us/articles/intel-ipp-static-libraries/

Hardware:  The latest dual-core/Quad Core machine with Windows xp/Windows Vista/Windows 7

2. Download and Unzip the Resize_Image_PS_VS2005.zip to a directory, let's name <WorkDIR>

3. Go to <WorkDIR> and double click the Resize Image.sln.  The msvc2005 IDE will prompt automatically.

4. From the main toolbar select Project>> Intel Parallel Composer 2011 » Select Build Component.

(or right-click the Project in Solution Explorer) , check Use IPP. click OK

5. Then build the application, from the main toolbar select Build >> Build solution

Please see the build details in  Use Intel IPP in Intel® Parallel Composer

How to run the application 

1. Run the application
From the main toolbar, select Debug >> Start Without Debugging. The application windows start, Click Open File, Select LennaC1.bmp 

2. click menu "Process => Resize image" to Resize the image. 
 Enter the zoom factor in horizontal (x) and vertical (y) directory in Resize dialog box.  Click OK  

3: Click lennC1.bmp and repeat step 2 again, make sure click button USE_IPP. Then get the below image  

IPP Function Adoption: 
Assume the sample is the application we want to improve the performance via IPP function.  
1.  Find the c code resize image function in RESIZE.cpp

unsigned long C_Code_Resize(unsigned char * src, int srcWidth, int srcHeight,   int srcStep, unsigned char* dst, int dstWidth, int dstHeight, int dstStep, double m_zoom_x, double m_zoom_y, int interpolation)

 It is called by function ProcessImage(CSampleDoc *pSrc) in ippiAddC.cpp

2. Check ipp manual ippiman.pdf and find the function ippiResizeSqrPixel have same functionality.  Then replace the C function with IPP function.  
Declare a similiar function in RESIZE.cpp
unsigned long IPP_Resize( void* src, int srcWidth, int srcHeight,int srcStep,  void* dst,  int dstWidth, int dstHeight, int dstStep, double m_nzoom_x, double m_nzoom_y, int interpolation)

 And call it in ProcessImage(CSampleDoc *pSrc) in ippiAddC.cpp instead of call C_Code_Resize().  (In order to compare the performance, we keep the c function call here.)

 if (m_USE_IPP)
{
             ippStaticInit();
       //---- perform IPP Funtion Code to rotate a image  -----//
         run_time = IPP_Resize(pSrc->DataPtr(),pSrc->Width(),pSrc->Height(),pSrc->Step(),(Ipp8u*)pDst->DataPtr(),        pDst->Width(),pDst->Height(),pDst->Step(),m_zoom_x,m_zoom_y,m_Interpolation);
}
else{         //---- perform C Code to rotate a image  -----//
         run_time = C_Code_Resize((unsigned char *)pSrc->DataPtr(),pSrc->Width(),
         pSrc->Height(),pSrc->Step(), (unsigned char *)pDst->DataPtr(), pDst->Width(),pDst->Height(),pDst->Step(),m_zoom_x,m_zoom_y,m_Interpolation);
}     

3. Write the IPP code to replace the C code.  The table show the original C code and the IPP code 

Tthe C code

The IPP code

unsigned long C_Code_Resize(unsigned char * src, int srcWidth, int srcHeight,int srcStep, unsigned char* dst, int dstWidth, int dstHeight, int dstStep, double m_zoom_x, double m_zoom_y, int interpolation) {//---------- Perform 1 order linear ---      //define record time variable      unsigned long start_clock,stop_clock;    start_clock = RUNTIME;      const unsigned char *tmpSrc;     unsigned char *tmpRef;     int width = srcWidth;     int height = srcHeight;     double xInv = 1.0 /  m_zoom_x;     double yInv = 1.0 /  m_zoom_y;     int colInd, rowInd;     int i, j, xSrc0, xSrc1, ySrc0, ySrc1, wdroi, hdroi;     int idxl, idyt, icol, jrow;     double row, col;     double y1, y2, y3, y4, v, v1, v2, tempV,tempV2;      idxl=0;      idyt=0;      wdroi = dstWidth;     hdroi = dstHeight;      tmpSrc = src; for(int kloop=0;kloop<LOOP;kloop++)  {     tmpRef = dst ;     for (j = 0, jrow = idyt; j < hdroi; j++, jrow++) {         row = (jrow + 0.5) * yInv - 0.5;         rowInd = (int)floor(row);         ySrc0 = ts_iGetCoord_vs(rowInd, rowInd,  0, srcHeight, srcHeight);         ySrc1 = ts_iGetCoord_vs(rowInd, rowInd + 1, 0, srcHeight, srcHeight);         for (i = 0, icol = idxl; i < wdroi; i++, icol++) {              col = (icol + 0.5) * xInv - 0.5;             colInd = (int)floor(col);             xSrc0 = ts_iGetCoord_vs(colInd, colInd,   0, srcWidth, srcWidth);             xSrc1 = ts_iGetCoord_vs(colInd, colInd + 1, 0, srcWidth, srcWidth);             y1 = (double)tmpSrc[ySrc0 * srcStep + xSrc0];             y2 = (double)tmpSrc[ySrc0 * srcStep + xSrc1];             y3 = (double)tmpSrc[ySrc1 * srcStep + xSrc0];             y4 = (double)tmpSrc[ySrc1 * srcStep + xSrc1];    ts_iLinearCalcSP_vs(col + 0.5, colInd + 0.5, colInd + 1.5, y1, y2, &v1);            ts_iLinearCalcSP_vs(col + 0.5, colInd + 0.5, colInd + 1.5, y3, y4, &v2); ts_iLinearCalcSP_vs(row + 0.5, rowInd + 0.5, rowInd + 1.5, v1, v2, &v);               //(ts_isaturate_vs(v);             tempV = (int)(v + EXP + 0.5);             tmpRef[i] =(unsigned char)((tempV > 255) ? 255 : (tempV < 0) ? 0 : tempV);         }         tmpRef += dstStep;   }   }      stop_clock = RUNTIME;      int mhz;     ippGetCpuFreqMhz(&mhz);      return (stop_clock - start_clock)/mhz/LOOP; }

unsigned long IPP_Resize(void* src, int srcWidth, int srcHeight,int srcStep,  void* dst,  int dstWidth, int dstHeight, int dstStep,   double m_nzoom_x, double m_nzoom_y, int interpolation)   {       //   define record time variable     unsigned long start_clock,stop_clock;     start_clock= RUNTIME;  // define IPP function parameter      IppiRect srcRoi = {0,0, srcWidth, srcHeight};      IppiRect dstRoi={0,0, dstWidth,dstHeight};        IppiSize srcSize = {srcWidth, srcHeight};     IppiSize dstSize = {dstWidth, dstHeight};        int BufferSize;      ippiResizeGetBufSize(srcRoi, dstRoi, 1, interpolation, &BufferSize);      Ipp8u* pBuffer=ippsMalloc_8u(BufferSize);        for(int i=0;i<LOOP;i++)          //---------- Perform IPP function:ippiResizeSqrPixel_8u_C1R  -------------------------------------------//      ippiResizeSqrPixel_8u_C1R((Ipp8u*)src, srcSize, srcStep, srcRoi, (Ipp8u*)dst, dstStep, dstRoi, m_nzoom_x,m_nzoom_y,0, 0, interpolation, pBuffer);     ippsFree(pBuffer);     stop_clock = RUNTIME;       int mhz;     ippGetCpuFreqMhz(&mhz);      return (stop_clock - start_clock)/mhz/LOOP;

Performance Gain 

On one test machine (core 2 Quad 2.66GHz), as the result image show that the performance gain is 15654/353=44x.

The test is linking serial IPP static library.  As the ippiResize is threaded in dynamic library and threaded IPP static library. If enable the multithread, the performance gain will be more than 50x (depends on the core numbers and image size).

Conclusion
Intel® Parallel Studio 2011 provide developer a first suit of tool for easy developing parallel application on multi-core platform. IPP is part of key component of Intel® Parallel Studio. It provide over thousands highly-optimizated functions that offer the support for for developing high performance digital media application. This article describes a brief way to adopt IPP function instead of source code via Parallel Studio Project and gain over 40x performance speed up outright.  

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

The low-level primitives within the Intel IPP library generally represent basic atomic operations. This limits threading within the library to ~15-20% of the functions. OpenMP is enabled by default when you use one of the multi-threaded variants of the Intel IPP library. A list of the threaded primitives in the IPP library is provided in the ThreadedFunctionsList.txt file located in the library’s doc directory.

The quickest way to multi-thread an Intel IPP application is to use the built-in OpenMP threading of the library. There’s no significant code rework required on your part and, depending on the IPP primitives you use, it may provide additional performance improvements.

IPP Internal Threading Model

If you use multiple threads in your own application (above the Intel IPP library) we generally recommend that you disable the library’s built-in threading. Doing so eliminates competition between the library’s OpenMP threading and your application’s threading, and avoids oversubscription of software threads to the available hardware threads.

Disabling internal IPP library threading in a multi-threaded application is not a hard and fast rule. For example, if your application has just two threads (e.g., a GUI thread and a background thread) and the IPP library is only being used by the background thread, using the internal IPP threading probably makes sense.

For a quick summary of the differences between OpenMP and other threading technologies please read Intel® Threading Building Blocks, OpenMP, or native threads?

Controlling OpenMP Threading in the Intel IPP Primitives

The default maximum number of OpenMP threads used by the multi-threaded IPP primitives is equal to the number of hardware threads in the system, which is determined by the number and type of CPUs in your system. That means that a quad-core processor with Intel® HT has eight hardware threads (four cores, each core has two threads), and a dual-core CPU without Intel HT has only two hardware threads.

There are two IPP primitives for control and status of the OpenMP threading used within the library: ippSetNumThreads() and ippGetNumThreads(). You call ippGetNumThreads to determine the current thread cap and ippSetNumThreads to change the thread cap. ippSetNumThreads will not allow you to set the thread cap beyond the number of available hardware threads. This thread cap is an upper bound on the number of threads that can be used within a multi-threaded primitive. Some IPP functions may use fewer threads than specified by the thread cap, but they will never use more than the thread cap.

To disable OpenMP threading within the library you need to call ippSetNumThreads(1) near the beginning of your application. Or, you can link your application with the single-threaded variant of the library.

The OpenMP library used by the IPP library references several configuration environment variables. In particular, OMP_NUM_THREADS sets the default number of threads (the thread cap) to be used by the OpenMP library at run time. However, the IPP library will override this setting by limiting the number of OpenMP threads used by your application to be either the number of hardware threads in the system, as described above, or the value specified by a call to ippSetNumThreads, whichever is smaller. OpenMP applications on your system that do not use the Intel IPP library might still be affected by the OMP_NUM_THREADS environment variable; likewise, any such OpenMP applications will not be affected by a call to the ippSetNumThreads function within your Intel IPP application.

Nested OpenMP

If your application that is using the Intel IPP library also implements multi-threading via OpenMP, the threaded Intel IPP primitives your application calls may execute as single-threaded primitives. This happens when an IPP primitive is called within an OpenMP parallelized section of code and if nested parallelization has been disabled, which is the default case for the Intel OpenMP library.

By nesting parallel OpenMP regions you risk creating a large number of threads that can effectively oversubscribe the number of hardware threads available. Creating parallel region always incurs overhead, and the overhead associated with nesting parallel OpenMP regions may outweigh the benefit.

In general, OpenMP threaded applications that use the IPP library should disable multi-threading within the library, either by calling ippSetNumThreads(1) or by using the single-threaded static Intel IPP library.

Core Affinity

Some of the Intel IPP primitives in the signal processing domain are designed to execute parallel threads that exploit a merged L2 cache. These functions (single and double precision FFT, Div, Sqrt, etc.) need a shared cache in order to achieve their maximum multi-threaded performance. In other words, the threads within these primitives should, ideally, execute on CPU cores located on a single die with a shared or unified cache. To insure this condition is met, the following OpenMP environment variable should be set before an application using the Intel IPP library runs:

KMP_AFFINITY=compact

On processors with two or more cores on a single die, this condition is satisfied automatically and the environment variable is superfluous. However, for those systems with more than two dies (e.g., a Pentium D or a multi-socket motherboard), where the cache serving each die is not shared, failing to set this OpenMP environmental variable can actually result in performance degradation for this class of multi-threaded Intel IPP primitives.

Additionally, some IPP functions require that Intel Hyper-Threading Technology is disabled or not used by the multiple threads within the Intel IPP mult-threaded library. This has been seen to negatively impact, for example, the performance of the IPP cryptography sample based on OpenSSL. In this case you should follow the instructions in this KB article:

IPP Crypto Sample Performance for OpenSSL too Slow on Hyper-Threading Systems

Multi-threaded FFT Functions

The multi-threaded FFT functions were originally developed as part of the v8/u8 libraries (Core 2 with a shared cache architecture). These functions specifically exploit a shared-cache architecture in order to achieve higher performance in a multi-threaded environment. If this shared-cache condition is not met you may see a performance degradation.

As noted above, for processors that use libraries higher than the v8/u8 optimization (e.g., p8/y8), you must set the  KMP_AFFINITY environmental variable equal to "compact" (as shown above) to avoid this potential performance degradation.

Within the FFT functions, threading starts with and order of 12 for 64fc data types and an order of 13 for 32fc data types.

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

clock():   The granularity of clock() function is dependent on implementation by various compiler vendors.  The C standard does not say anything about the granularity of clock() - a compiler can have it check time once a second and increment the variable by CLOCKS_PER_SEC. This means it is possible that, depending on different compiler implementation, you can get zero, CLOCKS_PER_SEC, CLOCKS_PER_SEC * 2 and so on, never getting any intermediate value. Don't use clock() if you need high granularity.

gettimeofday():  It returns time in milliseconds or the wall clock time. The precision of gettimeofday is also very bad, for example, for a 3 GHz machine that means precision == 3 million of cpu clocks only. If your application does only calculations, clock() and gettimeofday() would be fairly close. Any time, if the application starts waiting for something  (for  e.g: DISK  I/O), clock() will lag behind  compared to the gettimeofday().  clock() can also go faster than gettimeofday() if you have multiple threads running in the same process.

ippGetCpuClocks():  The IPP function ippGetCpuClocks() provides precision equals to 1 cpu clock.  If you want to get the highest granularity or precision, we highly recommend you to use ippGetCpuClock(). This can be used even your program is parallel and runs on multiple cores - all TSC counters are synchronized and show the same clocks as like there is the only one counter in a system.

The Intel® C/C++ Compiler version 11 also includes support for AES-NI, see How to Compile for the Intel® Core^TM i5 processor with AES-NI, as does Microsoft* Visual Studio* 2008 Service Pack 1 compiler and gcc version 4.4.

How to Download the Cryptography Library Add-on for the Intel IPP Library

The cryptography component of the IPP library is subject to US Export Administration Regulations and other US laws. To obtain the Intel IPP cryptography libraries, which must be downloaded separately, register for eligibility and follow the instructions you receive in the registration email. If you have additional questions review this knowledge base article on how to download the cryptography library component of the IPP library.

You must have a valid Intel IPP license key to install and use the Intel IPP libraries.

To see an advantage of AES-NI optimization in the crypto engine, refer to AES-NI demo. 

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804