RustFFT.jl v0.2: AbstractFFTs interface and performance improvements

A while ago I released the first version of RustFFT.jl and I received two major pieces of feedback: you should implement the AbstractFFTs interface, and it’s kinda slow. This release takes care of both.

First of all, the AbstractFFTs interface has been implemented. Computing the FFT of some data is as simple as calling fft(data) and you should be able to use RustFFT.jl as a drop-in replacement for other packages that implement this interface. Several custom options that are specific to this package are available if you use the planning interface.

The second part of the title, performance improvements, can be backed up with benchmark results. I’ve compared RustFFT.jl and FFTW.jl by running the following code to measure the minimum runtime:

@btime plan * data setup = (data = ones(ComplexF64, j); plan = plan_fft!(data))

j is incremented from 2 to 128 in steps of 1, and from 256 to 4096 in steps of 256. These benchmarks have also been run with optimized settings that skip several default checks and reuse a planner:

const planner64 = new_planner(ComplexF64)
@btime plan * data setup = (data = ones(ComplexF64, j); plan = plan_fft!(data; rustfft_checks=IgnoreArrayChecks(), rustfft_planner=planner64))

An overview of the results of these benchmarks on my PC can be found here

Let’s zoom in on the first 128 elements, and look at the ratio of runtimes between RustFFT and FFTW.

While there are many cases where FFTW.jl is faster than RustFFT.jl, the overall trend is that RustFFT.jl is approximately twice as fast as FFTW.jl for powers-of-two sizes.




That’s amazing! Is there any plan to support multi-dimensional data?

it is multithreaded?

It should be possible to support that in the future, the big drawback is that the elements have to be reordered. I expect that FFTW will be faster for higher-dimensional FFTs but I have to measure that to be sure.

1 Like

No, RustFFT is currently single-threaded. There’s an issue informing about the possibility: Is it possible enable multi-threading in RustFFT? · Issue #117 · ejmahler/RustFFT · GitHub

1 Like

So this is a single threaded RustFFT.jl vs. single threaded FFTW.jl?
This is really impressive. Could you add comparison to MKL based FFT?

By the way, I think it makes more sense to use random values instead of ones().

I’ve run the benchmarks on my laptop, which has an Intel CPU, and updated the results. I agree that random data would be better but I forgot to change it

Edit: yes, these benchmarks only compare single-threaded performance.