Add FFTW builder

[ViralBShah]

Fix #5

I copied the build_tarballs.jl from the FFTW Builder repo.

[ViralBShah]

cc @ararslan @stevengj

[stevengj]

You might want to copy some of the other changes from JuliaMath/FFTWBuilder#1, namely disabling Neon and switching to llvm-ranlib on MacOS. Oh, nevermind, I forgot that was already merged.

[stevengj]

At some point it would be good to use --enable-avx512 on Intel as well, but last I checked the BinaryBuilder compiler didn't support the -mavx512f flag.

(Note that enabling instructions like these is safe, if the compiler supports them, because FFTW checks at runtime which instructions are supported by the CPU and disables any unsupported code.)

[ViralBShah]

Do the recent changes to build GMP and MPFR better also help with AVX 512? @staticfloat Should we try to use the AVX512 now, or enable in a future build?

[staticfloat]

We can request newer versions of GCC very easily within BB now, so compiler support should not be an issue. The question is whether or not FFTW is polymorphic on CPUID or unconditionally uses AVX512; if the former, there's no problem, but if the latter, we do not yet have a seamless way for Julia to decide to use one artifact over another based on CPU capabiltiies.

[staticfloat]

I'm going to build tarballs for this version; then enable AVX512 and inspect it to figure out what it does.

[stevengj]

The question is whether or not FFTW is polymorphic on CPUID

FFTW is polymorphic on CPUID.

(See here for how it detects AVX512: https://github.com/FFTW/fftw3/blob/c5c85fe618a93bf6e41489bb65b6bf4e27224ff1/simd-support/avx512.c#L34-L62)

[staticfloat]

Fantastic. I'll enable everything then.

[staticfloat]

AVX512 is failing when building for MacOS due to FFTW/fftw3#153

Switching over to gcc explicitly works, so we're going with that.

[ararslan]

Does that not affect FreeBSD, or are we using GCC there too?

[staticfloat]

It is a problem with clang so we'd want to use GCC on FreeBSD as well.

[staticfloat]

I also need to sneak -fno-asynchronous-unwind-tables into the CFLAGS on x86_64-w64-mingw32, to avoid https://sourceforge.net/p/mingw-w64/mailman/message/36287627/

[staticfloat]

@stevengj you can use this as your new build_fftw.jl file: https://gist.github.com/staticfloat/fa9f64190f2c2234d624af3682b7da1f

[stevengj]

(I seem to recall that gcc produced faster code for FFTW anyway, when I checked it a few weeks ago. However, if you have an AVX-512 machine you can test FFTW/fftw3#177.)

[stevengj]

@staticfloat, why was v3.3.9-alpha1 troublesome (2814d23)?

[staticfloat]

why was v3.3.9-alpha1 troublesome (2814d23)?

The version itself is used to build the versions of the JLL package, and Pkg itself doesn't take kindly to releases with build numbers or prerelease tags. It's a defect that we're going to need to fix in 1.4, but for now I'm doing my best not to trigger it.

[ViralBShah]

Should FFTW.jl point to the binaries produced here (unless it is already done)?

[stevengj]

@ViralBShah, already done (JuliaMath/FFTW.jl#105) and tagged (JuliaRegistries/General#3297).