pffft fftpack.c fftpack.h test

PFFFT: a pretty fast FFT. ## TL;DR PFFFT does 1D Fast Fourier Transforms, of single precision real and complex vectors. It tries do it fast, it tries to be correct, and it tries to be small. Computations do take advantage of SSE1 instructions on x86 cpus, Altivec on powerpc cpus, and NEON on ARM cpus. The license is BSD-like. ## Why does it exist: I was in search of a good performing FFT library , preferably very small and with a very liberal license. When one says "fft library", FFTW ("Fastest Fourier Transform in the West") is probably the first name that comes to mind -- I guess that 99% of open-source projects that need a FFT do use FFTW, and are happy with it. However, it is quite a large library , which does everything fft related (2d transforms, 3d transforms, other transformations such as discrete cosine , or fast hartley). And it is licensed under the GNU GPL , which means that it cannot be used in non open-source products. An alternative to FFTW that is really small, is the venerable FFTPACK v4, which is available on NETLIB. A more recent version (v5) exists, but it is larger as it deals with multi-dimensional transforms. This is a library that is written in FORTRAN 77, a language that is now considered as a bit antiquated by many. FFTPACKv4 was written in 1985, by Dr Paul Swarztrauber of NCAR, more than 25 years ago ! And despite its age, benchmarks show it that it still a very good performing FFT library, see for example the 1d single precision benchmarks here: http://www.fftw.org/speed/opteron-2.2GHz-32bit/ . It is however not competitive with the fastest ones, such as FFTW, Intel MKL, AMD ACML, Apple vDSP. The reason for that is that those libraries do take advantage of the SSE SIMD instructions available on Intel CPUs, available since the days of the Pentium III. These instructions deal with small vectors of 4 floats at a time, instead of a single float for a traditionnal FPU, so when using these instructions one may expect a 4-fold performance improvement. The idea was to take this fortran fftpack v4 code, translate to C, modify it to deal with those SSE instructions, and check that the final performance is not completely ridiculous when compared to other SIMD FFT libraries. Translation to C was performed with f2c ( http://www.netlib.org/f2c/ ). The resulting file was a bit edited in order to remove the thousands of gotos that were introduced by f2c. You will find the fftpack.h and fftpack.c sources in the repository, this a complete translation of http://www.netlib.org/fftpack/ , with the discrete cosine transform and the test program. There is no license information in the netlib repository, but it was confirmed to me by the fftpack v5 curators that the same terms do apply to fftpack v4: http://www.cisl.ucar.edu/css/software/fftpack5/ftpk.html . This is a "BSD-like" license, it is compatible with proprietary projects. Adapting fftpack to deal with the SIMD 4-element vectors instead of scalar single precision numbers was more complex than I originally thought, especially with the real transforms, and I ended up writing more code than I planned.. ## The code: Only two files, in good old C, pffft.c and pffft.h . The API is very very simple, just make sure that you read the comments in pffft.h. ## Comparison with other FFTs: The idea was not to break speed records, but to get a decently fast fft that is at least 50% as fast as the fastest FFT -- especially on slowest computers . I'm more focused on getting the best performance on slow cpus (Atom, Intel Core 1, old Athlons, ARM Cortex-A9...), than on getting top performance on today fastest cpus. It can be used in a real-time context as the fft functions do not perform any memory allocation -- that is why they accept a 'work' array in their arguments. It is also a bit focused on performing 1D convolutions, that is why it provides "unordered" FFTs , and a fourier domain convolution operation. Benchmark results -- The benchmark shows the performance of various fft implementations measured in MFlops, with the number of floating point operations being defined as 5Nlog2(N) for a length N complex fft, and 2.5*Nlog2(N) for a real fft. See http://www.fftw.org/speed/method.html for an explanation of these formulas. 2021 update: I'm now including Intel MKL, and I'm removing old benchmarks results for cpu that have not been relevant for a very long time.. Now that most Intel cpus have AVX enabled (most but not all, Intel is still selling cpus with no AVX), the performance of pffft vs MKL or VDSP is a bit behind since pffft is only SSE2. However, performance of pffft on the Apple M1 cpu is very good (especially for the real fft), so I'll put it first :-) MacOS Big Sur, XCode 12, M1 cpu on a 2020 mac mini. I'm not including fftw results as they are very bad here, most likely Homebrew did not enable neon when building the lib. clang -o test_pffft -DHAVE_VECLIB -O3 -Wall -W pffft.c test_pffft.c fftpack.c -framework Accelerate | input len |real FFTPack| real vDSP | real PFFFT |cplx FFTPack| cplx vDSP | cplx PFFFT | |-----------:|-----------:|-----------:|-----------:|-----------:|-----------:|-----------:| | 64 | 4835 | 15687 | 23704 | 12935 | 36222 | 33046 | | 96 | 9539 | n/a | 25957 | 11068 | n/a | 32703 | | 128 | 11119 | 33087 | 30143 | 12329 | 50866 | 36363 | | 160 | 11062 | n/a | 32938 | 11641 | n/a | 34945 | | 192 | 11784 | n/a | 35726 | 12945 | n/a | 39258 | | 256 | 13370 | 44880 | 40683 | 14214 | 64654 | 42522 | | 384 | 11059 | n/a | 40038 | 11655 | n/a | 39565 | | 480 | 10977 | n/a | 40895 | 10802 | n/a | 36943 | | 512 | 12197 | 34830 | 43353 | 12357 | 78441 | 41450 | | 640 | 11685 | n/a | 43393 | 11775 | n/a | 39302 | | 768 | 12314 | n/a | 45836 | 12756 | n/a | 43058 | | 800 | 11213 | n/a | 41321 | 10842 | n/a | 37382 | | 1024 | 13354 | 45214 | 50039 | 13759 | 93269 | 45210 | | 2048 | 12806 | 57047 | 49519 | 12908 | 99361 | 43719 | | 2400 | 10972 | n/a | 43399 | 10928 | n/a | 37574 | | 4096 | 13957 | 65233 | 52845 | 13851 | 105734 | 46274 | | 8192 | 12772 | 70108 | 49830 | 12560 | 85238 | 40252 | | 9216 | 12281 | n/a | 48929 | 12114 | n/a | 39202 | | 16384 | 13363 | 62150 | 48260 | 12910 | 79073 | 38742 | | 32768 | 11622 | 60809 | 32801 | 11145 | 71570 | 35607 | | 262144 | 11525 | 53651 | 34988 | 10818 | 63198 | 36742 | | 1048576 | 11167 | 46119 | 34437 | 9202 | 38823 | 31788 | So yes, the perf of the M1 cpu on the complex is really impressive... Windows 10, Ryzen 7 4800HS @ 2.9GHz, Visual c++ 2019 and Intel MKL 2018 Build with: cl /Ox -D_USE_MATH_DEFINES -DHAVE_MKL /arch:SSE test_pffft.c pffft.c fftpack.c /I c:/MKL/include c:/MKL/lib/intel64/mkl_intel_lp64.lib c:/MKL/lib/intel64/mkl_sequential.lib c:/MKL/lib/intel64/mkl_core.lib | input len |real FFTPack| real MKL | real PFFFT |cplx FFTPack| cplx MKL | cplx PFFFT | |-----------:|-----------:|-----------:|-----------:|-----------:|-----------:|-----------:| | 64 | 3938 | 7877 | 14629 | 7314 | 25600 | 19200 | | 96 | 5108 | 14984 | 13761 | 7329 | 20128 | 20748 | | 128 | 5973 |