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.
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.
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.