CPU spikes first time a specific function is used

[gol]

We have some troubles using IPP for audio, the (very) first time (not sure if it's after a reboot, sometimes it seems to happen again on the same boot) some functions are used, they eat quite a lot of CPU, enough to cause audio hickups in the whole engine the first time you access specific features that use those functions.

One of those functions is IppsConv_xxx (but there are others), and -most likely- it's due to the threading scheme that's created the first time such functions need to be multithreaded.

So I thought, no problem, I will just "break in" those function when the application is created, so that the glitches won't happen during use. So I call a IppsConv_xxx on a huge block of data (1024 for both buffers, filled with 0.1, not zeros to avoid a potential detection/optimization of empty buffers), hoping that this would break in/run in the function. But that doesn't work. One thing is that I'm doing this "break in" in the main GUI thread, while the functions are typically used in side worker threads. Is the threading scheme used by some IPP functions linked to the calling thread, should I try to break in those functions at the beginning of each worker thread instead? Or is there a better way to do this?

Still using IPP6 btw.

[Chao_Y_Intel]

Hi,

Is the application linked with threaded IPP libraries (dynamic or threaded static), or none-threaded libraries? IppsConv_xx is internally threaded. Since the application is threaded at the high level, with the nested IPP function threading, the application may be over-threaded A good practices is that if the application is threaded at the high level, you can use single threaded IPP functions.

Thanks,
Chao

[gol]

Threaded. But the thing is, sometimes the app will be overthreaded, sometimes not, it depends of other plugins in the host, and on the number of voices being played (it's a synthesizer, & voices are threaded too). Better be overthreaded than underthreaded (these days, at least. And I never much liked how CPUs went to multicore)

But still, after the first call, the CPU usage is efficient, it's really that first call that causes troubles. I've tried running in in each worker thread, not sure it helped (well it seems to require a reboot each time), I saw a spike but a smaller one. It's not a huge problem but I thought there was an easy solution.