ippiResizeSqrPixel_8u_C1R performance issues

[Roman_Golomidov]

Hi,

have some strange performance problems withippiResizeSqrPixel_8u_C1R.

This code:

[cpp] s = ippiResize_8u_C1R( &source[start], sd, sd.width, srcRoi, destination, dd.width, dd, ddimension->scaleX, ddimension->scaleY, interpolation); [/cpp]

interpolation isIPPI_INTER_CUBIC

app running on intel atom D525 use around 15-20% cpu according to top.

butippiResize_8u_C1R is deprecated in favor toippiResizeSqrPixel_8u_C1R.

It have pretty same params, so code changed to

[cpp] IppiRect dstRoi; dstRoi.x = 0; dstRoi.y = 0; dstRoi.width = dd.width; dstRoi.height = dd.height; s = ippiResizeSqrPixel_8u_C1R(&source[start], sd, sd.width, srcRoi, destination, dd.width, dstRoi, ddimension->scaleX, ddimension->scaleY, 0.0, 0.0, interpolation, video_private->ipp_buffer); [/cpp] app starts using around 250-300% CPU :(

Have tryed all methods in interpolation - result the same - very high cpu usage.

What I doing wrong?

I need to resize YUV422 picture. Prior, i needippiDeinterlaceMedianThreshold_8u_C1R.

So source YUV422 i convert to planes byippiYCbCr422ToYCbCr420_8u_C2P3R

and the operating by each plane separately.

Linux Debian, GCC 4.7.1, ipp 7.0/7 (latest), 64bit

Regards,

Roman.

[pvonkaenel · Accepted solution]

I believe the ResizeSqrPixel function is listed as one of the threaded routines in the IPP library. You should be able to disable the threading by linking againstthe un-threaded static libraries, or by calling (I think) ippSetNumThreads(1). Out of curiosity, in addition to the higher CPU utilization, do you also see faster resize performance?

Peter

[SergeyKostrov]

Hi Roman,

Quoting Roman Golomidov

...app starts using around 250-300% CPU :(...

Do you mean your application is working 2.5x - 3x slower?

On the Performance page of the Windows Task Manager a CPU Usage can not be greater than 100%. How did you get'250-300%' numbers?

Best regards,
Sergey

[Roman_Golomidov]

You absolutely right!

It must beeclipse of my mind those 300% cpu not pointed me into threads direction.

When I set ippSetNumThreads(1) app start using ordinar 20-25% CPU as with deprecated function.

App is doing real time process. So even if function itself works faster, app dont run faster - cause no more data arrived.

Thank you!

Roman

[Roman_Golomidov]

App is real time and its not noticable to see it work faster.

I run 6 those apps at the same time and it was very confusing to see in top list 6 processes with 250% CPU usage :)

In linux when you use threads it could be easy when app reports 100% x number of threads CPU usage.

[SergeyKostrov]

Hi Roman,

Quoting Roman Golomidov

You absolutely right!

It must beeclipse of my mind those 300% cpu not pointed me into threads direction.

When I set ippSetNumThreads(1) app start using ordinar 20-25% CPU as with deprecated function.

App is doing real time process...

Thanks for the note. Please take into account that Intel IPP library is not designed for Real-Time applications.
It is 'OpenMP-Threaded' and all OpenMP threads work with 'Normal' priorities and they could be preemted from
executioncompletely by some 'Real-Time' process or thread. Even if I have a couple of test-cases with IPP functions
that could work when a process priority is set toReal-Time I don't use it in real applications. I didn't see significant
performance improvements in my test-cases I've mentioned.

Did you try 'Above Normal' or 'High' process priorities?

[Roman_Golomidov]

By "real time" here I mean, app operates on data what coming as time goes. So even if app make 2x faster crunching data, it will have 2x more empty cycles, but will not finished 2x faster (actually it is great if it will never stops :)

I manually force priority a little bit up (pr 15 against 20 normal, but it is not real time priority anyway).

[SergeyKostrov]

Quoting Roman Golomidov

By "real time" here I mean, app operates on data what coming as time goes...

I see. You wanted to tell "run-time". Thanks for clarifying it.