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.