At least in MATLAB the MKL FFTW also makes use of the ESTIMATE planner by default. Hence, I would be surprised it the MKL version in julia would enforce the use of MEASURE. Especially, since creating a plan with MEASURE should take a lot longer than it does by default.
Oh youâre right, just checked it⌠Ok, then I totally miss why MKL version behaves so much better with defaults. I guess it goes as intel magicâŚ
The comparison above is with Matlab fft, but Julia transforms all dimensions by default, which should be compared with Matlabâs fftn.
On an m1, if I compare with something column major
x = randn(1001,128,128) + 1j*randn(1001,128,128)
f = @() fftn(x)
timeit(f)
takes 64ms in Matlab 2022a, while
using LinearAlgebra, FFTW, BenchmarkTools
x=randn(ComplexF64,1001,128,128);
FFTW.set_num_threads(8)
p = plan_fft(x,flags=FFTW.MEASURE)
y=deepcopy(x);
@btime mul!($y,$p,$x);
in Julia 1.8.0 takes
21.374 ms (136 allocations: 9.53 KiB)
The issue is that MEASURE plans require a large start-up latency, so they are only useful if you know you are going to be performing many FFTs of the same sizes. Interactive users wouldnât appreciate this.
I donât know where Matlab uses MKL and where it uses FFTW, but I suspect that for FFTW it pre-packages âwisdomâ (precomputed plans) for a set of common sizes (powers of 2 and powers of 10, probably) and otherwise uses ESTIMATE plans.
Yes, thatâs exactly what they do , but for the powers of two only.
Sure, I had misunderstood what Matlab does. Prepackaged wisdom seems to be a nice solution for enhanced user experience. (Still 1001 is a very bad length for FFTs, hence out of scope for any reasonable wisdom prepackaging, so this should not apply to the previously discussed test cases).
The MKL backend doesnât support 1 dim planning? When I use
p = plan_fft(x,1)
, it says
FFTW could not create plan
But the FFTW backend works perfectly.