Intel provides two FFT libraries - one in MKL (“Math Kernel Library”) and one in IPP (“Integrated Performance Primitives”).
I wasn’t aware of this fact until I was looking into switching code which uses an Intel FFT to use JUCE’s new wrapper of an Intel FFT. I then found out that my colleague’s code uses Intel IPP while JUCE wraps Intel MKL.
So what are the differences? which one is better? which should I use?
Intel provides a comparison page which says that for “media and communications” (“Signal processing”, “Audio coding”, “Speech coding and recognition”) IPP is the right choice, and that it is “specifically designed for smaller problem sizes including those used in multimedia” and “embedded C/C++ applications”.
KFR’s fft benchmark compares to IPP and FFTW but doesn’t even mention MKL. So this implies that according to them IPP is the obvious choice between the too?
Does anyone have additional data about this? Does anyone know why JUCE chose MKL rather than IPP?
I also find this a bit irritating, especially since the Projucer has a dedicated field for choosing the IPP linking type, so I’d guess they’ve settled on the IPP path.
Disclaimer: the IPP property in the Projucer was a dedicated feature request from myself
I also find the choice of the more generic MKL library a bit bizarre. I already use the IPP in my project for other stuff, so having to link the MKL again (and not even have proper Projucer support to do it) seems a bit redundant.
Don’t mean to hijack this, but specifically with the FFT are the IPP and MKL versions bit exact relative to each other? And is one faster than the other?
It looks like Intel first made IPP with the focus of having the best performance (according to wp v2 is from 2002).
I guess they then found out that many users won’t use it rather than FFTW because it isn’t feature complete (nothing that concerns us - JUCE only wraps power-of-2 ffts anyhow), so they released MKL’s FFT at 2003 with the focus of having the same features and API as FFTW, so that FFTW users could use it as a drop-in replacement. But it appears not to be as fast as IPP.
EDIT: Corrected by Mathieu below that MKL and FFTW’s interfaces differ
To be honest, I wasn’t aware that IPP also had an FFT. I’ve been using MKL for a while now - I should have done my research.
Is it really true that IPP is significantly faster? Would seem strange to me as MKL is already highly optimised by the same engineers. Also, MKL is freely available to use - is this also true for IPP?
If there is a good reason to add IPP then we’ll definitely do so.
All the scientific Intel libraries are now free (IPP, MKL, TBB…) even for commercial usage (TBB was Open source, but not usable for commercial purposes without agreeing to the GPL IIRC).
One major reason for me, is that the IPP is already supported by the projucer. For the MKL we need to add include paths, linker paths and library names. For IPP we flip a switch.
Makes it MUCH easier to use.
The IPP is also able to take some shortcuts, as it’s designed with audio/video in mind, whereas the MKL is more for scientific computing and more general.
I agree. I ran into the same confusion… MKL option for Juce’s FFT, but also the option in the Projucer to flag that IPP can be used (for what actually?).
I use IPP for convolution (and thus FFT/IFFT). For Eq spectrums I started with the JUCE FFT, but will have to port that to IPP. I do not want to link to MKL as well.
PS to @Rail_Jon_Rogut: drawing paths take much more time than Juce’s basic FFT (at for instance size 1024). I am also very interested to see the difference in performance between the basic Juce FFT and the IPP FFT for such short sizes. Not yet tested or timed in release mode.