is there a way tos elect what version of IPP to build against (VisualStudio)

seems like it always uses latest installed ipp 

Running this code with IPP 7.1:

static const int w = 11, h = 11;
static const IppiSize roi = {w,h};
static const IppiSize roi3 = {w*3,h};

Ipp8u src8[w*h*3] = {
	128,128,128,118,118,118,128,128,128,  0,  0,  0, 29, 29, 29,  0,  0,  0, 71,  0,  0,132,  0,  0, 56,  0,  0,  0,  0,  0,  0,  0,  0,
	126,126,126,110,110,110,119,119,119, 73, 73, 73,106,106,106, 32, 32, 32,163,  0,  0,233,  0,  0, 94,  0,  0,  0,  0,  0,  0,  0,  0,
	128,128,128,128,128,128,150,150,150, 62, 62, 62, 45, 45, 45,  0,  0,  0, 39,  0,  0,118, 30,  0, 55,  0,  0,  0,  0,  0,  0,  0,  0,
	 90, 90, 90, 43, 43, 43, 94, 94, 94, 72, 72, 72,252,252,252,  0,  0,  0,101,101,  0, 68, 68,  0,118,118,  0, 22, 30,205,  0,  0,  0,
	106,106,106,194,194,194, 45, 45, 45,187,187,187,255,255,255,247,247,202,179,179,  0,185,185,  0,  0,  3,117,  0,  9,225,  0,  6,113,
	 25, 25, 25,127,127,127,  0,  0,  0,118,118,118,198,198,198,113,113, 52, 61, 61,  0,174,174,  0,  0,  8,161,  0,  7,151,  0,  6,113,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  7,135,  0,  0,  0,
	240,  0,205,254,  0,219,254,  0,219,254,  0,220,254,  0,220,254,  0,220,254,  0,220,254,  0,220,254,  0,220,254,  0,219,243,  0,210,
	240,  0,205,254,  0,219,254,  0,219,255,  0,220,255,  0,221,255,  0,221,255,  0,221,255,  0,221,255,  0,219,254,  0,219,243,  0,210,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
};

float src[w*h*3], tmp[w*h*3], dest[w*h*3];
int step = w*3*sizeof(float);
ippiScale_8u32f_C1R(src8, w*3, src, step, roi3, 0, 1);

ippiRGBToLUV_32f_C3R(src, step, tmp, step, roi);
ippiLUVToRGB_32f_C3R(tmp, step, dest, step, roi);

double norm = 0;
ippiNormDiff_Inf_32f_C1R(src, step, dest, step, roi3, &norm);

I expect src and dest be almost identical, but they differ significantly (norm == 107374176.00000000, which is greater than the [0,1] range of RGB data). Looking at dest, I see that half the values are -107374176. Here are the first few values of dest:

[0]: 0.501961112, [1]: 0.501960814, [2]: 0.501960516,
[3]: 0.462745398, [4]: 0.462745130, [5]: 0.462744951,
[6]: 0.501961112, [7]: 0.501960814, [8]: 0.501960516,
[9]: 0.000000000, [10]: 0.000000000, [11]: 0.000000000,
[12]: -107374176., [13]: -107374176., [14]: -107374176.,
[15]: -107374176., [16]: -107374176., [17]: -107374176.,
[18]: -107374176., [19]: -107374176., [20]: -107374176.,
[21]: -107374176., [22]: -107374176., [23]: -107374176.,
[24]: -107374176., [25]: -107374176., [26]: -107374176.,
[27]: -107374176., [28]: -107374176., [29]: -107374176.,
[30]: -107374176., [31]: -107374176., [32]: -107374176.,
[33]: 0.494117767, [34]: 0.494117677, [35]: 0.494117856,
[36]: 0.431372792, [37]: 0.431372553, [38]: 0.431372404,
[39]: 0.466667026, [40]: 0.466666609, [41]: 0.466666490,
[42]: 0.286274731, [43]: 0.286274493, [44]: 0.286274403,

I did the same with Ipp16u data type, and everything is OK (norm == 3.0 out of 65535).

Please verify my interpretation that this behavior is indeed incorrect, and if so, let me know if the bug (?) is fixed in IPP 8.0.

Thanks,

Yakov Galka

On a computer with IPP 4.0 and IPP 6.0 a program using IPP 4.0 is loading the ippcc.dll from IPP 6 which I don't understand. In the end OMP aborts with the problem described here: https://software.intel.com/en-us/articles/opm-abort-initializing-libguide40dll

Is this the result of any automated mechanism from the DLL dispatcher of IPP 4.0?

Any help is appreciated...

Good afternoon.

I'm linking some libs we are developing for Android with libimf.a but I'm getting these errors:

/home/public/projects/android/ndk-linux-r9d-standalone/api-9/x86/bin/i686-linux-android-c++  -I../../../include -I../../../../fn/include  -I../../../../img/include -I../../../../comm/include  -DHAVE_PTHREADS -DIPP -D_REENTRANT -D__EXTENSIONS__ -D_POSIX_PTHREAD_SEMANTICS -I/home/public/projects/android/ipp-8.1.0.003/include -ffor-scope -Wall -W -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -fstrict-aliasing -Woverloaded-virtual    -fPIC -ffunction-sections -fdata-sections -fexceptions -fsigned-char  -O3 -fdiagnostics-show-option -fomit-frame-pointer  android/gcc/i686/imagerotation.o ../../../../fn/lib/android/gcc/i686/libfn.a /home/public/projects/android/3rd-party/cryptopp-5.6.2/lib/ndk-r9d/android/gcc/i686/libcrypt.a /home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libippi.a /home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libipps.a /home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libippcore.a /home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libimf.a /home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libirc.a /home/public/projects/android/3rd-party/LibJPEG-90/lib/ndk-r9d/android/gcc/i686/libjpeg.a /home/public/projects/android/3rd-party/LibPNG-1.5.12/lib/ndk-r9d/android/gcc-4.8/i686/libpng.a /home/public/projects/android/3rd-party/CharLS-82415/lib/ndk-r9d/android/gcc/i686/libCharLS.a /home/public/projects/android/3rd-party/LibJASPER-1.900.1/lib/ndk-r9d/android/gcc/i686/libjasper.a /home/public/projects/android/3rd-party/LibTIFF-4.0.2/lib/ndk-r9d/android/gcc/i686/libtiff.a /home/public/projects/android/3rd-party/ZLib-1.2.7/lib/ndk-r9d/android/gcc/i686/libz.a   -o android/gcc/i686/imagerotation  -Wl,--gc-sections   -lm -ldl -lgnustl_shared

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libimf.a(libm_error.o):real/libm_error.c:function write_message: error: undefined reference to 'catgets'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libimf.a(libm_error.o):real/libm_error.c:function write_message: error: undefined reference to 'stderr'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libimf.a(libm_error.o):real/libm_error.c:function write_message: error: undefined reference to 'catopen'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libimf.a(libm_error.o):real/libm_error.c:function write_message: error: undefined reference to 'catopen'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libimf.a(libm_error.o):real/libm_error.c:function write_message: error: undefined reference to 'stderr'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libimf.a(libm_error.o):real/libm_error.c:function __libm_error_support: error: undefined reference to '__errno_location'

collect2: error: ld returned 1 exit status

As far as I know __errno_location doesn't even belong to Android. Adding a cxx-stl/llvm-libc++/libs/x86/libc++_static.a I can get rid of the catgets and catopen errors, but stderr remains and I haven't found an Android lib containing it, as opposed to the libc linux libs.

Compilation chain uses the same include/libpath, despite it should be irrelevant as the problem comes from libimf.a. I'm using a single function from ippi (ippiRotate_32f_C1R), so I'm including #include <ippi.h> in the source. Trying to link without libimf would deal into:

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libippi.a(pirotate_g9---ownpi_Rotate.o):pirotate_g9---ownpi_Rotate.i:function g9_ownpi_Rotate: error: undefined reference to '__libm_sse2_sincos'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libippi.a(pirotate_w7---ownpi_Rotate.o):pirotate_w7---ownpi_Rotate.i:function w7_ownpi_Rotate: error: undefined reference to '__libm_sse2_sincos'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libippi.a(pirotate_s8---ownpi_Rotate.o):pirotate_s8---ownpi_Rotate.i:function s8_ownpi_Rotate: error: undefined reference to '__libm_sse2_sincos'

/home/public/projects/android/3rd-party/ipp-8.1.0.003/lib/i686/libippi.a(pirotate_h9---ownpi_Rotate.o):pirotate_h9---ownpi_Rotate.i:function h9_ownpi_Rotate: error: undefined reference to '__libm_sse2_sincos'

collect2: error: ld returned 1 exit status

Am I doing something wrong? Is it a bug in the ipp support in Android?

All the best,

Alejandro.

The entry for ippiGradientVectorScharr shows a kernel identical to that shown for ippiGradientVectorPrewitt with sample weights of magnitude [1, 1, 1].  I believe for the Scharr gradient filter the kernel weights should be of magnitude [3, 10, 3].  This appears to be a simple copy/paste error in the document.

I know ippiResizeSqrPixel has obsoleted. So I want to use ippiResizeLinear replace it.

But I would like to know to set source ROI and destination ROI(like ippiResizeSqrPixel).

 Thanks.

Hi,

The IPP 7.1 H264 decoder caused segmentation fault by leaving only the following line in the debugger's stack: s8_h264_interpolate_luma_type_0_width_16_sse2 () from /usr/lib/libippvcp8.so.7.1

is this a known problem or the new one?

It seems to be caused by h264 stream that has peculiar values, but why is it crashing? Decoder should never crash.

Anyone?

Vladimir Pavlovic

Let me know if you've heard this before!

I am trying to write an ipps-based function that does something like following MatLab code:

result = ifft( theFT.*conj(theFT) );

Here, theFT is a complex vector and multiplying by its conjugate yields the squared magnitude, which is real. We then get the inverse real fft.

My questions are about formatting the data efficiently for IPP. If I call MagSquared, that gives me a real vector, but I need something in perm (or pack or ccs) format to pass to ippsFFTInv. Is there a convenient function for converting from real to perm? If not, should I write my own function to compute the magnitude and store it in perm format?

thanks for your attention

Dear all,

I need a help.

I try to using ippsAndC_16u_I function on IPP 8.0 on my projects.

When I have tested on windows 7, the result is speed up. But on XP is not only lower than windows 7 but also lower than normal case.

I try to find out solution to fix it. And I have read release notes of IPP 8.0 

https://software.intel.com/en-us/intel-ipp-80-library-release-notes.

I see "Intel® IPP static libraries are not compatible with Microsoft Windows Driver Development Kit* 2003. "

That is the reason, my project does't speed up ?

I am in the process of upgrading an existing application from IPP 7.0 to IPP 8.1. I make use of the routine ippiMorphReconstructDilate in my application. My question is, when I attempt to compile my application, I get a compilation warning that the symbol "ippiMorphReconstructGetBufferSize_" has been deprecated as of IPP 7.1. 

ippreconstruct.cpp:37:5: error: ‘IppStatus ippiMorphReconstructGetBufferSize_8u_C1(IppiSize, int*)’ is deprecated (declared at ../../../../../../toolbox/shared/ipp/include/glnxa64/ippcv.h:1545): is deprecated. This function is obsolete and will be removed in one of the future IPP releases. Use the following link for details: http://software.intel.com/en-us/articles/intel-ipp-71-deprecated-features/ [-Werror=deprecated-declarations]

If you look at the IPP 8.1 documentation:

https://software.intel.com/sites/default/files/managed/13/8d/ippi.pdf

the example for ippiMorphReconstructDilate still makes use of ippiMorphReconstructGetBufferSize to determine the size of the buffer that is still a required input argument of the  ippiMorphReconstructDilate interface. 

My questions are:

My question(s) are:

1) Why is ippiMorphReconstructGetBufferSize deprecated, and was

MorphReconstructDilate also intended to be put on deprecation?

2) If MorphReconstructDilate is not supposed to be deprecated, how am I supposed to allocate the argument "pBuf", the second to last input argument:

IPPAPI(IppStatus, ippiMorphReconstructDilate_8u_C1IR, (const Ipp8u* pSrc,int srcStep,Ipp8u* pSrcDst, int srcDstStep, IppiSize roiSize, Ipp8u *pBuf,IppiNorm norm))

3) Is there another routine that I'm supposed to use to allocate the buffer required by ippiMorphReconstructDilate? Is there an example where I can see this being done?

Hi, IPP developers,

  I am working on one Moorefield project which uses IPP to optimize some CV modules. Since morrefield is a 64-bit capable platform and default image has been 64-bit version, so to make best performance we want to also work as 64-bit. But current IPP release has only 32-bit version, which is  a  problem to us? Do you have  any 64-bit version plan for IPP Android(Atom)?

Hi,

Here is a simple question. I'm new to IPP and I'm trying to understand how to use it for solving the following problem:

A += B*C + D*E + F*G + ...

A, B, C, D, E, F, G, ... are all matrices of the same size, * represents standard matrix multiply. The sizes of the matrices are small, typically between 3x3 and 35x35. 

IPP provides a routine - I'm looking at the ippmMul_mama_64f function - that would operate on two source arrays of matrices, in our case: [B, D, F] and [C, E, G], producing, as far as I understood, three output matrices A1, A2, and A3, storing the results of B*C, D*E, and F*G, respectively. Now I have two correlated questions:

- In my problem, there's a single output matrix A. Is there a function in IPP, or a safe way of using ippmMul_mama_64f, such that the results are *accumulated* in a single output matrix A, rather than in three different matrices A1, A2, and A3?

- If this is not possible, how do I best combine the three temporaries A1, A2, and A3?

Ah, incidentally: is there any document I can look at that compares the performance of IPP MX to hand-crafted implementatios? I've done a bit of research and I couldn't find much.

Thanks

-- Fabio

Hello,

I have an issue with hppWait and hppiSAD. My target configuration is:

Intel ® (R) Atom CPU E3845 @ 1.91 Ghz (4 cores)

Windows 8 Enterprise (32-bit)

Intel Graphics Driver 10.18.10.3496 (3/11/2014)

IPP Preview 2014 February (2014.feb).

SSE42 instruction set / IvyBridge

The issue is basically that, for a specific instance of template matrix (100x100) and GPU acceleration, the hppWait function did not return. The issue was only observed on the target specified above. No problems were observed when using the AVX2 instruction set/ Haswell GT2 configuration.

Workarounds included :

1. Changed HPP_TIME_OUT_INFINITE to a specific timeout value, so that the error code from hppWait could be accessed and analyzed. This was not successful, since the hppWait function never returned, even with a specified timeout value.


2. Changed the template matrix specification : 8x8, 16x16, & 32x32 all worked, in lieu of 100x100.

Other symptoms of this issue were as follows:

1. When using the 100x100 template and the GPU accelerator, an Error Window would be displayed on the Windows 8 desktop  to say “Display Device Driver Stopped Working and has recovered..” This would always occur at the point in the execution sequence where hppiSAD was activated.


2. When using the 16x16 or 32x32 template specifications, the error messages below were observed:

[ERROR]   : CM EnqueueCopyGPUToCPUStride Failed: errCode=-56.

[ERROR]   : VAL ReadSurface error

[ERROR]   : m_pVAManager->ReadSurface Failed: erroCode=-156.

The associated hppWait call returned in this case, so the above error messages may or may not be related to the issue with the 100x100 template.

The code base under execution using the two different targets is the same, even though the hppWait failure to return was only observed on IvyBridge. I am not clear as to why the template size matters. This is a near term issue, mainly because it blocks execution of tests which are sequenced after hppiSAD invocation.

In trying to troubleshoot this issue, the hppiSAD function was invoked with two different scale factors. I have noted an earlier forum entry regarding negative hppiSAD scale factors resulting in erroneous hppWait return values. But I wanted to ask further about scale factor values  0 and 1. According to my testing, they are both legal, but from an internal processing perspective, is there a fundamental difference between the two ? How are the results different when these values are processed ?

Hi,

Does anyone knows how SSE absence in the CPU affects the performance of IPP library

I need to know what's the difference in performance (if any) can be between Intel processor with just AVX support versus Intel processor with both SSE and AVX support.

Can anyone help me with this question?

Thanks,

Oleg Fomenko

In the current implementation of mp3enc_writeFrame() inside the file mp3enc_bitstream.c, it is possible that we can encounter infinite loop while executing the code block below.

Whenever the code below gets called with resr_mod_slot = 1, we end up with an infinite loop.

Any suggestions on how to fix this ?

 do {

          Ipp32s left = resr_mod_slot;

          len = left < bytes ? left : bytes;

          for (i = 0; i < len; i++)

              *ptr_out++ = *ptr_main++;

          res += len;

          bytes -= len;

          resr_bytes -= len;

          resr_mod_slot -= len;

          if (resr_mod_slot < 0)

              resr_mod_slot += slot;

          if (len == left && si_num > 0) {

              for (i = 0; i < si_bytes; i++)

                  *ptr_out++ =

                      si_buf[si_beg][i];

              res += si_bytes;

              resr_bytes -= si_bytes;

              resr_mod_slot -= si_bytes;

              if (resr_mod_slot < 0)

                  resr_mod_slot += slot;

              si_num--;

              si_beg++;

              if (si_beg >= SI_MAX)

                  si_beg = 0;

          }

      } while(bytes)

 Hi~

 I currently use the UIC sample code.

 I want to convert IplImage to CIppImage. and to save *.jpg using the CIppImage type.

 So, i try to convert, but i can't save to *.jpg.

 For example, My sample code is

/////////////////////////////////////////////////////////////////////////////////////////////

    CIppImage         image;

    IM_TYPE           fmtIn;

    IM_TYPE           fmtOut;

    Ipp8u*            buf;

    CStdFileOutput  fo;    

    CMemBuffOutput  mo;

    fmtOut = IT_BMP;

    fo.Open(cmdOptions.dst);

    IplImage *img = cvLoadImage(cmdOptions.src,CV_LOAD_IMAGE_GRAYSCALE);

//    cvShowImage("test",cmdOptions.src);

//    cvSaveImage(cmdOptions.dst,img);

    

    image.Width(img->width);

    image.Height(img->height);

    image.Color(IC_GRAY);

    image.Format(IF_FIXED);

    image.Sampling(IS_444);

    image.ComponentOrder(0);

    image.NChannels(img->nChannels);    

    image.Precision(img->depth);

    image.Step(4096);

    image.DataPtr((Ipp8u*)img->imageData);    

    // Encoder

    BaseStream::TPosition pos = 0;  

    size = image.Step()*image.Height()*2;

    buf = (Ipp8u*)ippMalloc((int)size);

    mo.Open(buf, (int)size);

    res = EncodeImage(image, mo, cmdOptions, fmtOut, &encTime);

    mo.Position(pos);    

    mo.Close();

    fo.Write(buf, pos, cnt);

    ippFree(buf);

///////////////////////////////////////////////////////////////////////////////////////////////////////

   Thanks in advance for your help!

Version 8.1 removed the deprecation warnings for most of the in place functions. I am still however getting the warnings for ippiFilterBox. Are the in place functions for ippiFilterBox still slated for deprecation?

Thanks.

Nevine

Hi

Could someone please help me out on this core dump issue.  I tried to run IPP on my PC and I am getting core dump during execution.  

Program terminated with signal 4, Illegal instruction.

#0  0x00007fc545139206 in e9_ownsZero_8u_E9 () from /opt/intel/ipp/lib/intel64/libippsce9.so.8.0

Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.4.x86_64 libgcc-4.4.7-4.el6.x86_64 libstdc++-4.4.7-4.el6.x86_64

(gdb) bt full

#0  0x00007fc545139206 in e9_ownsZero_8u_E9 () from /opt/intel/ipp/lib/intel64/libippsce9.so.8.0

No symbol table info available.

#1  0x00007fc545115259 in e9_ippsZero_16s () from /opt/intel/ipp/lib/intel64/libippsce9.so.8.0

No symbol table info available.

#2  0x00007fc54507d72d in e9_ippsPhaseDispersionInit_G729D_16s () from /opt/intel/ipp/lib/intel64/libippsce9.so.8.0

No symbol table info available.

#3  0x000000000042a94a in apiG729Decoder_Init (decoderObj=0x7fc513f0c010, codecType=G729A_CODEC) at decg729.cpp:124

        i = 4

        fltSize = 108

        abDec = {8192, 15836, -7667, 7699, -15398, 7699}

        oldMemBuff = 0x7fc513f16010 ""

#4  0x0000000000478d0c in RTP_UpdateCodec (usnWorkUnitID=<value optimized out>, usnIndex=0, ubCallerCodec=<value optimized out>, ubCallerPayload=<value optimized out>, 

    ubCalledCodec=<value optimized out>, ubCalledPayload=<value optimized out>) at rtp_work_unit.cpp:1117

        s_MemBank = {pMem = 0x7fc513f35938 "\024", nbytes = 2048, align = 0, memType = USC_OBJECT, memSpaceType = USC_NORMAL}

        __FUNCTION__ = "RTP_UpdateCodec"

        c_pPlayWU = 0x26d9540

        s_pLine = 0x7fc513ee4010

        s_options = {minframesize = 0, framesize = 0, maxframesize = 0, pcmType = {sample_frequency = 8000, bitPerSample = 20, nChannels = 0}, modes = {reserved1 = 0, 

            reserved2 = 0, reserved3 = 0, reserved4 = 0}}

#5  0x000000000041873a in Proc_UPDATE_CODEC_CMD (pData=0x12b3305 "hJ&\001") at ctrl_work_unit.cpp:1724

        ulong = <value optimized out>

        s_pUserData = 0x1264a68

        un32RID = 3

        __FUNCTION__ = "Proc_UPDATE_CODEC_CMD"

        sIP = "192.168.1.107", '\000'<repeats 26 times>

        pMSG = 0x12b3311 ""

        un64Dest = 0

        ubCallerCodec = 2 '\002'

        ubCallerPayload = 0 '\000'

        usnType = <value optimized out>

        un64Source = 1399188723

        sHeader = '\000'<repeats 127 times>

        p = <value optimized out>

        ubCalledCodec = 3 '\003'

        ubCalledPayload = 18 '\022'

        s_pLine = 0x7fc513ee4010

#6  0x000000000041dced in CTRL_ProcessMessage (pData=<value optimized out>) at ctrl_work_unit.cpp:1964

        __FUNCTION__ = "CTRL_ProcessMessage"

#7  0x000000000041df92 in __CTRL_Proc_Thread (lpParameter=<value optimized out>) at ctrl_work_unit.cpp:2002

        __FUNCTION__ = "__CTRL_Proc_Thread"

        pData = 0x12b3305 "hJ&\001"

        ubSleepFlag = 0 '\000'

        ScanRTPLineStatusTime = 1401165272

---Type <return> to continue, or q <return> to quit---

        Time = <value optimized out>

#8  0x0000003195207851 in start_thread () from /lib64/libpthread.so.0

No symbol table info available.

#9  0x0000003194ee894d in clone () from /lib64/libc.so.6

No symbol table info available.

(gdb) 

[root@baohq bin]# cat /proc/cpuinfo 

processor    : 0

vendor_id    : GenuineIntel

cpu family    : 6

model        : 23

model name    : Pentium(R) Dual-Core  CPU      E5300  @ 2.60GHz

stepping    : 10

cpu MHz        : 1203.000

cache size    : 2048 KB

physical id    : 0

siblings    : 2

core id        : 0

cpu cores    : 2

apicid        : 0

initial apicid    : 0

fpu        : yes

fpu_exception    : yes

cpuid level    : 13

wp        : yes

flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dts

bogomips    : 5230.55

clflush size    : 64

cache_alignment    : 64

address sizes    : 36 bits physical, 48 bits virtual

power management:

processor    : 1

vendor_id    : GenuineIntel

cpu family    : 6

model        : 23

model name    : Pentium(R) Dual-Core  CPU      E5300  @ 2.60GHz

stepping    : 10

cpu MHz        : 1203.000

cache size    : 2048 KB

physical id    : 0

siblings    : 2

core id        : 1

cpu cores    : 2

apicid        : 1

initial apicid    : 1

fpu        : yes

fpu_exception    : yes

cpuid level    : 13

wp        : yes

flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dts

bogomips    : 5230.55

clflush size    : 64

cache_alignment    : 64

address sizes    : 36 bits physical, 48 bits virtual

power management:

Linux baohq 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

They are great in performance but the problem is that the libraries designed and developed in native C language and could be used in unmanaged C/C++ programs. Today many of programmers used to program in managed language such as C#, Managed C++, ... in dot net platform. Using unmanged IPP and MKL libraries in Managed languages are so hard. I think designing and developing a managed object oriented Interface for these libraries would be great improvement that will bring easy to use performance gain for all new programmers.

I receive "Access denied" on Volume 3: Small Matrices and Realistic Renderin PDF file (https://software.intel.com/en-us/ipp_8.1_ippm_pdf)

Other files downloaded correctly (https://software.intel.com/en-us/articles/intel-integrated-performance-p...)