# Why FFTW was not written in Fortran?

**URL:** <https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415>\
**Category:** Uncategorized\
**Created:** [November 10, 2020, 6:35am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415 "2020-11-10T06:35:36Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\
**Post date:** [November 10, 2020, 6:35am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/1 "2020-11-10T06:35:36Z")

</div>

I was wondering why the FFTW was not written in Fortran?

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 10, 2020, 6:49am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/2 "2020-11-10T06:49:07Z")

</div>

[http://www.fftw.org/faq/section2.html#whynotfortran](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.

---

<div class="post-metadata">

**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\
**Post date:** [November 10, 2020, 7:13am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/3 "2020-11-10T07:13:42Z")

</div>

That is interesting; Concise and precise.

---

<div class="post-metadata">

**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\
**Post date:** [November 10, 2020, 7:17am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/4 "2020-11-10T07:17:03Z")

</div>

That means even highly professional people write libraries based on the personal interest and liking.

---

<div class="post-metadata">

**Author:** ![billlong](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@billlong](https://fortran-lang.discourse.group/u/billlong)\
**Post date:** [November 10, 2020, 10:09pm UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/5 "2020-11-10T22:09:02Z")

</div>

The most likely reason is that the authors did not know Fortran. That is very commonly the case in academia.

---

<div class="post-metadata">

**Author:** ![zerothi](https://avatars.discourse-cdn.com/v4/letter/z/c5a1d2/32.png) [@zerothi](https://fortran-lang.discourse.group/u/zerothi)\
**Post date:** [November 13, 2020, 11:13am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/6 "2020-11-13T11:13:10Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 13, 2020, 11:50am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/7 "2020-11-13T11:50:18Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\
**Post date:** [November 13, 2020, 12:32pm UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/8 "2020-11-13T12:32:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![billlong](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@billlong](https://fortran-lang.discourse.group/u/billlong)\
**Post date:** [November 13, 2020, 2:55pm UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/9 "2020-11-13T14:55:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![milancurcic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/milancurcic/32/2_2.png) [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)\
**Post date:** [November 13, 2020, 3:03pm UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/10 "2020-11-13T15:03:39Z")

</div>

> [@ivanpribec](#):
>
> > 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.

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.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [November 13, 2020, 4:28pm UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/11 "2020-11-13T16:28:13Z")

</div>

A few years ago I benchmarked [FFTPACK](https://www.netlib.org/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.

---

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [November 14, 2020, 5:04pm UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/12 "2020-11-14T17:04:35Z")

</div>

> [@milancurcic](#):
>
> > [@ivanpribec](#):
> >
> > > 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.
> 
> When authors write this, we better believe it. No need to make up technical reasons for or against.

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.

---

<div class="post-metadata">

**Author:** ![fortran4r](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fortran4r](https://fortran-lang.discourse.group/u/fortran4r)\
**Post date:** [January 2, 2022, 4:04am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/16 "2022-01-02T04:04:09Z")

</div>

FFTE is written in Fortran.

[http://www.ffte.jp/](http://www.ffte.jp/)

> **[GitHub - project-gemmi/benchmarking-fft: choosing FFT library...](https://github.com/project-gemmi/benchmarking-fft)**
>
> choosing FFT library... Contribute to project-gemmi/benchmarking-fft development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [January 3, 2022, 1:43am UTC](https://fortran-lang.discourse.group/t/why-fftw-was-not-written-in-fortran/415/17 "2022-01-03T01:43:00Z")

</div>

> [@fortran4r](#):
>
> FFTE is written in Fortran.
> 
> [http://www.ffte.jp/](http://www.ffte.jp/)

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)](https://github.com/certik/ffte), 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.
