Setting Thread priorities causes ippiFilter_32f_C1R() to take too long !!!!

Setting Thread priorities causes ippiFilter_32f_C1R() to take too long !!!!

Hi!

In the following code we set a thread priority to THREAD_PRIORITY_HIGHEST (Win32 API). This effects the ippiFilter_32f_C1R() in a most perculiar way. The function now takes more than 10 seconds. If we set a thread priority to THREAD_PRIORITY_NORMAL, the function takes less than 1 ms.

Can anyone explain why ?
More details : VC.Netand VC++6, Win2K and WinXP.

#include "Windows.h"
#include "ipp.h"
#pragma comment (lib,"ippi20.lib")
int main()
{
// SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_NORMAL);
SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_HIGHEST); Ipp32f pSrc[100*100];
Ipp32f pDst[100*100];
int srcDestStep = 100*sizeof(Ipp32f);
int ROIStartIndex = 100*2 + 1;
IppiSize filterRoiSize={96,96};
const Ipp32f pKernel[25]= {1,1,1,1,1,
1,1,1,1,1,
1,1,1,1,1,
1,1,1,1,1,
1,1,1,1,1};
const IppiSize kernelSize ={5,5};
IppiPoint m_anchor = {2,2};
ippiFilter_32f_C1R(&pSrc[ROIStartIndex],srcDestStep,&pDst[ROIStartIndex],srcDestStep,filterRoiSize,pKernel,kernelSize,m_anchor);
return 0;
}

Thanks
Maurice

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi,Zmau
I have test your code , found just 1 ms difference .
VC.Net and P4 ,XP

Hi all, I have the answer now.

First of all, I am a newby so my terms will be inexact, so I will ask everyones to excuse (and correct my terminology if I am wrong).

IPP lib can be used in 2 ways :

1) Creates extra threads for doing the computation
2) No extra threads.

This problem happens when you work with IPP with the first method. Now the extra threads are created (with a default priority) but they have different priorities then "My thread" (becuase I had changed my threads priority above). Now I do not have Hyper Threading, so the whole game is done on my CPU. Now, the job is being split between the threads but in order for me to return from this ipp function all threads should finish their part. Now the method probably chosed by intel for these thread to wait for other threads id (once again : probably) "busy wait", i.e. the thread is holding the CPU, expecting other threads to work on the second CPU. remeber that I have only one CPU (NO HT), so "My thread" with a high priority is occupying the CPU, until Windows raises the priorities of other threads (by it's logic of starvation, which takes longer the more I raise "My thread's" priority).

I hope I am clear with this explanation.

To make things short : working in the second mode (i.e. no extra threads) worked great, and was not effected by the priority bussiness.

Thanks for the effort.
Maurice

Hi,

you are right. We have OpenMP threading support embedded into IPP DLLs, and we do not have OpenMP support in static libraries. So you can choose which options will fit your needs.

Regards,
Vladimir

Leave a Comment

Please sign in to add a comment. Not a member? Join today