// ippSetNumThreads(1);
    for (i=0; i<100; i++)
    {
       ippiCFAToRGB_8u_C1C3R(pRAWData, srcRoi, srcSize, img_orig.step, pRGBData1, img_debayer.step, grid, 0); 
       Sleep (20000);
    }

Root Cause : 

Seeing from the above scenarios, they have same features:
1. Using IPP build-in thread function on multi-threads environment (multi-core machine or own thread).
    for example, ippiResize is not threaded, but ippResizeSqrPixel is threaded.
2. Using the threaded function intermittently. For example, call function with a interval of 200ms.

In general, it is true that the high cpu usage usually corresponds to better performance.
For example, calling the IPP threaded function repeatedly on 4 core machines,  
for (i=0; i<100; i++){
       ippiCFAToRGB_8u_C1C3R(pRAWData, srcRoi, srcSize, img_orig.step, pRGBData1, img_debayer.step, grid, 0); 
}
when without openMP threading, the cpu usage is 25% (1 of 4 core), take 10ms,
and when OpenMP threading is on, the cpu use 100% (full 4 core). it takes 2.5ms.
So for highly optimized functions, when one thread is used, it will take 25% cpu and when all of core are used, the cpu usage go to 100% is expected.

But if intermittently call the threaded functions, i.e 30 times a second, the cpu usage arise from 3% to 88%, this causes overall performance to drop so much that it is impossible to use IPP threaded function in real application. 

The problem is actually caused by a feature of OpenMP threads execution mode.  As we know, IPP threaded function is using OpenMP threading internally (libiomp5*.lib/dll).  When IPP threaded function run in OpenMP threads, in order to get good performance, the threads or the workers (libiomp5* library=>kmp_lauch_worker) will keep active for next work until no more new work come in. Such mechanism is efficient if these threads are reserved solely for OpenMP execution. But for many application which happened to call the function intermittently and contains no-thread code (i.e. sleep()) in parallel region. The OMP threads will wait each times, after completing the work of ipp function call in a parallel region, before sleeping. Such "wait" (default is 200 milliseconds) cause the cores busy, therefore abnormally high cpu usage.  

Here is more information about OpenMP thread execution mode:
http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedprojects/optaps_for/common/optaps_par_libs.htm

In addition, calling and IPP threaded in external thread may cause high cpu usage because the overhead for nest parallel.  See more from OpenMP and the Intel® IPP Library

Resolution : 

1. Avoid the problems(intermittent IPP function call and nested threads) completely by calling ippSetNumThreads(1)

2. For who still hope to keep IPP build-in thread functionatlity, you may change the IPP OpenMP thread execution mode by 
    setting environment variable in system, KMP_BLOCKTIME=0 
    or setting it before run your application.
    >set KMP_BLOCKTIME=0
    >run.bat
    or call OpenMP function kmp_set_blocktime(0). 

Notes*: The function kmp_set_blocktime() is from Intel OpenMP* run-time library libiomp*.lib/dll. Please see more from http://www.intel.com/software/products/compilers/docs/clin/main_cls/mergedProjects/optaps_cls/common/optaps_par_exrt.htm

Reference Number : DPD200139993


Version : 11.1


Product : Intel® C++ and Visual Fortran Compilers for Windows* and Intel® Parallel Composer


Operating System : Windows*


Problem Description : When using /Qipo from the Microsoft Visual Studio* IDE (/Qipo is enabled by default in C++ release configurations), /Qvec-reportN has no effect.  You may see this when using the compiler with /Qipo from the command-line as well, but make sure that you're passing /Qvec-reportN at link-time in that case, as it will only have an effect on the second pass phase of IPO.  You will need to link with icl.exe if that is the case, because xilink.exe (used by the IDE and usable from the command-line) has no option to enable vectorization messages.


Resolution Status : Our compiler driver developers are working on adding support for modifying the vectorization message verbosity to xilink.exe in a future compiler version.  The only way to get vectorization messages at this time is to use /Qvec-reportN, and either:

1. Disable /Qipo.  Note that you may not get a vectorizer report that exactly matches what you would get if you used IPO, as IPO might be able to eliminate loops entirely that would then not be vectorized, or enable vectorization where the compiler would not be ordinarily able to identify the loop as being safely vectorizable, but the vectorization report you do get should be useful.
or
2. Pull the linker line from the Visual Studio* buildlog and use icl.exe on the command line to link.  This will require some work to happen, as you will need to pull the object files more to the front, and then add the /link option to separate the compiler command options like /Qvec-report and /Qipo from the linker options.  For example, the buildlog will list the linker options as:

<linker options>
a.obj
b.obj
c.obj
<rest of objects>

And you would have to create a command line like:

icl.exe /Qipo /Qvec-report3 a.obj b.obj c.obj <other objects> /link <linker options>



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200136749


Version : 10.1, 11.0, 11.1


Product : Intel® C++ Compilers Professional Edition for Windows* and Linux*.  Intel ® Parallel Composer.


Operating System : Windows* versions prior to Windows Vista* or equivalent, Linux*


Problem Description : When using precompiled headers, you may see the diagnostic:

Warning #677: memory usage conflict with precompiled header file

This means that there was an internal problem with the precompiled header processing in the compiler and precompiled headers will not be used for the file in question which may cause an increase in build times.


Resolution Status : We are investigating this issue.  Please contact us via the User Forum or Intel® Premier Support if you are experiencing this issue.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200084693


Version : 11.1.038


Operating System : Windows


Problem Description : 

Following case will get unresolved external symbol error at linking stage if use c++ stream to pass numerical variables with option /Qlong_double specified.

Case: test006.cpp

#include <stdio.h>
#include <iostream>
using namespace std;
int main()
{
            int x=0;          //line 6
            cout << x;      //line 7
}

Command:

icl /Od /Ob1 /Qlong_double /MDd test006.cpp 

Fail Output:

 -out:test006.exe
test006.obj
test006.obj : error LNK2001: unresolved external symbol "protected: virtual class std::ostreambuf_iterator<char,struct std::char_traits<char> > __thiscall std::num_put<char,class std::ostreambuf_iterator<char,struct std::char_traits<char> > >::do_put(class std::ostreambuf_iterator<char,struct std::char_traits<char> >,class std::ios_base &,char,UNKNOWN)const " (?do_put@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@MBE?AV?$ostreambuf_iterator@DU?$char_traits@D@std@@@2@V32@AAVios_base@2@D_T@Z)
test006.exe : fatal error LNK1120: 1 unresolved externals

 

While if changing line 6 & 7 to following,  the test will link fine: 

char x='0';          //line 6
cout << x;          //line 7

Currently only using the option combination like "/Ob{1|2} /Qlong_double /MD[d]" and the use of C++ stream to pass numerical variable will trigger this link failure.  

Resolution Status : 
This issue is fixed after Intel(R) C++ Compiler Windows* Update 3.


[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200084262


Version : 11.1.038 for Windows running on Intel(R) 64


Operating System : Windows x64 edition


Problem Description : 
The following program will get stack frame Run-Time Check(RTC) failure due to incompatible RTC stack frame check between Intel C++ Compiler for Windows and Microsoft* Visual C++ 2005 or 2008 for x64 run time library.

--- Program ---

void sub();

int main(int argc, char* argv[])
{
  sub();
  return 0;
}

void sub()
{
  int i;
  __declspec(align(64)) float aiueo[256];

  for (i=0;i<256;i++)
    aiueo[i] = 0;

  return;
}

--- RTC error message ---

Run-Time Check Failure #2 - Stack around the variable 'result.38007' was corrupted.

--- problem definition ---

If array "aiueo" is defined as align(32), align(64) or above, this failure will expose. If array "aiueo" is defined as align(8), align(16), this failure will be avoided.

This is a stack frame Run-Time Check(RTC: /RTCs) incompatible issue between Intel C++ Compiler for Windows and Microsoft Visual C++ Compiler for x64 platform run time library. The program binary is actually gengerated correctly.

Resolution Status : 

This has been fixed in the 11.1.046 C++ Compiler for Windows.

 

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200135511


Version : 11.1


Operating System : Windows*


Problem Description : The Boost* STL library's bind functionality uses a construct called placeholders to bind function arguments to a function.  Boost implements these placeholders in an anonymous namespace which the Intel® C++ Compiler has problems with when pre-compiled header files are used and debug symbol generation is enabled.  The following code demonstrates the problem (requires Boost* libraries).

pch.h:

#include <boost/bind.hpp>

pch.cpp:

#include "pch.h"

test-bind.cpp:

#include "pch.h" class blh_widge { public: void Init(); private: void OnInputComplete(int, int, int); }; void blh_widge::Init() { boost::bind(&blh_widge::OnInputComplete, this, _1, _2, _3) {} } int main() { return(0); }

Reproduce:

icl -Od -I<boost include> -Ycpch.h -Fptest-bind.pch -c -Zi pch.cpp icl -Od -I<boost include> -Yupch.h -Fptest-bind.pch -Zi test-bind.cpp test-bind.cpp Microsoft (R) Incremental Linker Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. -out:test-bind.exe -debug -pdb:test-bind.pdb test-bind.obj test-bind.obj : error LNK2019: unresolved external symbol "struct boost::arg<1> __N_13_test_bind_cpp_main::_1" (?_1@__N_13_test_bind_cpp_main@@3U?$arg@$00@boost @@A) referenced in function ___sti__?_1@__N_13_test_bind_cpp_main@@3U?$arg@$00@b oost@@A test-bind.obj : error LNK2019: unresolved external symbol "struct boost::arg<2> __N_13_test_bind_cpp_main::_2" (?_2@__N_13_test_bind_cpp_main@@3U?$arg@$01@boost @@A) referenced in function ___sti__?_2@__N_13_test_bind_cpp_main@@3U?$arg@$01@b oost@@A test-bind.obj : error LNK2019: unresolved external symbol "struct boost::arg<3> __N_13_test_bind_cpp_main::_3" (?_3@__N_13_test_bind_cpp_main@@3U?$arg@$02@boost @@A) referenced in function ___sti__?_3@__N_13_test_bind_cpp_main@@3U?$arg@$02@b oost@@A test-bind.exe : fatal error LNK1120: 3 unresolved externals

Resolution Status : This issue is resolved in the Intel® Parallel Composer Update 1 or Intel® C++ Compiler Professional Edition for Windows* 11.1.038.


[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : DPD200008448, DPD200137998


Version : All the 10.x, 11.x compilers and the older versions.


Operating System : Linux, Windows


Problem Description : 
    Test case 1: test.c
             int round(float in);
             int foo(float in)
             {
                  int res=round(in);
                  if(res !=0) res = 1;
                   return res;
              }

        Test case 2: test.c
              float memcpy(char*, char*, int);
              float res;
              void foo(char* in, char* out)
              {
                   res = memcpy(in, out, 100);
              }
     Test case 3: test.c
             double pow();
             void bar(double);
             void foo()
             {
                  int a=0;
                  int b[1]={255};
                  bar(pow(b[a],2));
             }
     compile the test case: icl test.c -c
The compiler will report the internal error 0_0, or the internal error 0_1279, or the internal error 0_1208 etc in difference cases.
This is the problem in all the cases where the compiler recognize something (defined by user differently than in compiler intrinsics table) being an intrinsic call and expand this call inline.
Resolution Status : 
1. Change the function name to your own name different to the compiler intrinsic function. For example, change 'round' in case 1 to 'myround', change 'memcpy' in case 2 to 'mymemcpy', change 'pow' in case 3 to 'mypow'.
2. Include the compiler head files to use the intrinsic functions provided by compiler instead of to define your own. Be carefull to the compiler warnings for incompatible declarations during compilation stage.



[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Reference Number : 
U66541 / DPD200137349

Version : 
Intel C++ compiler 11.1.035


Operating System : 
Windows


Problem Description :

When I change the project property in VS2003 to set the /Qfp-speculation to safe, the result in command line is not "/Qfp-speculation:safe", it is appearing as "/Qfp-speculationsafe" and we get error during compilation.

Resolution Status :


One needs to provide an argument to compiler /Qfp-speculation. The valid arguments are fast, safe, strict and off. The compiler option /Qfp-speculation from IDE is not being set properly. You may set this option from command line property page as work around.

We have tried /Qfp-speculation:safe in VS2008 from command line and there is no issue.




[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]