I was wondering why the FFTW was not written in Fortran?
1 Like
http://www.fftw.org/faq/section2.html#whynotfortran
Question 2.10. Why isn’t FFTW written in Fortran/C++?
Because we don’t like those languages, and neither approaches the portability of C.
Also note that the actual FFTW code in C is autogenerated by a program written in Ocaml.
3 Likes
That is interesting; Concise and precise.
That means even highly professional people write libraries based on the personal interest and liking.
2 Likes
The most likely reason is that the authors did not know Fortran. That is very commonly the case in academia.
1 Like
Well, I don’t think so. The FFTW library uses many branches with specific register extensions (SSE, AVX, AVX2, …), one reason for the OCAML code generation.
While these could be used with fortran it is simply more easy to integrate with C.
While we love Fortran we should also acknowledge when Fortran isn’t the right tool 
In this case I think they did it correctly 
3 Likes
I agree with @zerothi. Also note that FFTW was initially released in 1997, before C interoperability was standardized in Fortran 2003. Having to deal with different compiler name mangling schemes would be one of the arguments against using Fortran.
It appears to me that the basic idea about Fortran was efficient numerical computing but the additional extensions and operability reduced the usage and people shifted to other languages for ease.
Just to point out that the need for different implementations for SSE, AVX, AVX2 … is just a symptom of the problem that Intel never comprehended the idea of a “vector register”. On architectures with actual vector registers, FFT’s were routinely written in Fortran. The alternative was assembly, which is a lot easier to write for a RISC architecture than for a CISC scheme like x86.
When authors write this, we better believe it. No need to make up technical reasons for or against. “I don’t like X” is the ultimate argument that can’t be argued against.
When I program in Fortran, I do it because 1) I like it, and 2) it’s useful for some problems.
5 Likes
A few years ago I benchmarked FFTPACK written in Fortran, compiled using Intel compilers with all optimizations on, and it was faster than FFTW that was preinstalled at one of the HPC systems I tested this on. It turned out the issue was the preinstalled version of FFTW was not configured with AVX support. When I compiled FFTW myself, it was slightly faster, but FFTPACK was surprisingly competitive (I believe within a factor of 2x on the test cases that I tested), which is not bad at all for a library written in 1982. And this is a great example of the strengths of Fortran, which I would like to see more of.
9 Likes
Yes, there can no arguments when someone says they did it one way because they liked it that way.
But I would have liked to be able to challenge the authors’ point about “neither approaches the portability of C”. But unfortunately certain important platforms lag significantly with their support for Fortran (e.g., those in Apple ecosystem) which makes it rather difficult to make a case to a broader audience for Fortran even though it is one of its strengths.
Then there is the bugaboo of performance; interesting it didn’t get a mention in that answer to question 2.10. But again, unfortunately there are “benchmarks” out there which tend to combine data processing and IO along with numerical computations over relatively short run-times which makes it difficult for Fortran to distinguish itself anymore.
3 Likes
I put all releases into a git repository: GitHub - certik/ffte: FFTE: A Fast Fourier Transform Package (Official tarballs are unpacked into master as commits), but haven’t updated it with the more recent releases. I’ve used it in production, FFTE is a great library that scales well with MPI.
2 Likes