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

**URL:** <https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502>\
**Category:** Package Announcements\
**Created:** [August 4, 2023, 7:26pm UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502 "2023-08-04T19:26:15Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Taaitaaiger](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taaitaaiger/32/49792_2.png) [@Taaitaaiger](https://discourse.julialang.org/u/Taaitaaiger)\
**Post date:** [August 4, 2023, 7:26pm UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502/1 "2023-08-04T19:26:15Z")

</div>

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:

```julia
@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:

```julia
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](https://github.com/Taaitaaiger/RustFFT.jl/blob/main/comparison.png)

Let’s zoom in [on the first 128 elements](https://github.com/Taaitaaiger/RustFFT.jl/blob/main/comparison_128.png), and look at the [ratio of runtimes between RustFFT and FFTW](https://github.com/Taaitaaiger/RustFFT.jl/blob/main/comparison_ratio.png).

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.

[Github](https://github.com/Taaitaaiger/RustFFT.jl)

[Docs](https://taaitaaiger.github.io/RustFFT.jl/dev/)

---

<div class="post-metadata">

**Author:** ![photor](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/photor/32/14343_2.png) [@photor](https://discourse.julialang.org/u/photor)\
**Post date:** [August 5, 2023, 5:23am UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502/2 "2023-08-05T05:23:19Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rveltz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rveltz/32/2707_2.png) [@rveltz](https://discourse.julialang.org/u/rveltz)\
**Post date:** [August 5, 2023, 6:40am UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502/3 "2023-08-05T06:40:13Z")

</div>

it is multithreaded?

---

<div class="post-metadata">

**Author:** ![Taaitaaiger](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taaitaaiger/32/49792_2.png) [@Taaitaaiger](https://discourse.julialang.org/u/Taaitaaiger)\
**Post date:** [August 5, 2023, 9:12am UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502/4 "2023-08-05T09:12:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Taaitaaiger](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taaitaaiger/32/49792_2.png) [@Taaitaaiger](https://discourse.julialang.org/u/Taaitaaiger)\
**Post date:** [August 5, 2023, 9:14am UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502/5 "2023-08-05T09:14:30Z")

</div>

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](https://github.com/ejmahler/RustFFT/issues/117)

---

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [August 5, 2023, 1:31pm UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502/6 "2023-08-05T13:31:38Z")

</div>

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()`.

---

<div class="post-metadata">

**Author:** ![Taaitaaiger](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taaitaaiger/32/49792_2.png) [@Taaitaaiger](https://discourse.julialang.org/u/Taaitaaiger)\
**Post date:** [August 5, 2023, 5:35pm UTC](https://discourse.julialang.org/t/rustfft-jl-v0-2-abstractffts-interface-and-performance-improvements/102502/7 "2023-08-05T17:35:31Z")

</div>

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.