5 ms·

The question is why in 2020 R still uses a Fortran compiler?

by Thaxll 6y ago

_Wintermute 6y ago
Because it's R, it doesn't even have 64 bit integers yet.
- rodonn 6y ago
  It does with the bit64 package, but agree that I wish it was directly supported.
anbende 6y ago
This is answered in the article. Chunks of R are written in Fortran 90, which can’t be converted to C easily right now. You might ask why it’s written in Fortran at all. Probably has something to do with its history coming out of the S language at Bell labs in the 70s and 80s.
mmrezaie 6y ago
Fortran is domninant in HPC (Maybe not dominant, but there are a lot of software in HPC written in Fortran). R uses some performance oriented libraries which most likely implemented in Fortran.
uberman 6y ago
Fortan is berserkly fast.
bregma 6y ago
I'm sure someone will come along with a Rust rewrite any day now.
- mike_ivanov 6y ago
  I admire your sense of humor.
gh02t 6y ago
Tons of software are still using Fortran in the scientific/numerical world. NumPy and SciPy, for example, also make extremely heavy use of Fortran. As would many things that rely on BLAS/LAPACK. It's not just legacy code, either... Fortran is still very active in its own little niche in the numerical world.
- danpalmer 6y ago
  Yep, I think the issue with R is that they're using a customised version of BLAS/LAPACK – Python has been running these things on Raspberry Pis for ages now, I suspect using a more standard implementation.
  - em500 6y ago
    No, the issues are different, please read the article. R also runs fine on ARM64 linux. But macOS is not linux, as mentioned in the article it has a different ABI and no free Fortran 90 compiler is available yet. The other issue is that R distinguishes between NA values and NaN values (NumPy doesn't), which are propagated differently on ARM64.
  - gh02t 6y ago
    Based on the article I don't think those are the problem. I think the new Apple silicon is distinct enough that it needs a bit of porting effort to get a Fortran compiler running, along with the issue of quirks in handling NaN payloads and some other (seemingly rather minor) differences.
ryukafalz 6y ago
If it works well, why change it?
geofft 6y ago
Fortran is the standard implementation language for scientific computing in 2020. Try compiling NumPy and SciPy from source sometime.
baron_harkonnen 6y ago
Fortran is still a foundation of many important libraries for numeric computing. A fairly large number of implementations of BLAS are written in Fortran (including the reference implementation), LAPACK is written in Fortran. One of the first domains solved by programming was efficient implementations of common linear algebra computations. Fortran was the original language of choice for many of those projects. When you care about absolutely optimal performance for these computations you're not going to mess with fined tuned code that has been slowly tweaked and improved for over 50 years.
pdpi 6y ago
If I recall correctly, C and C++ allow some types of pointer aliasing that fortran forbids. If you're reading from one buffer and writing to another, those buffers can overlap in C or C++, but can't in fortran, so a fortran compiler is allowed more leeway with the way instructions are ordered (and maybe elided? Not sure). In compute-intensive workloads, every little bit helps.
- rlkf 6y ago
  Correct. Back in the days, it used to be that you could run Fortran 77 code through f2c and then compile with gcc using the assume-no-aliasing option, and you would get roughly the same performance as if you compiled with f77.
- johncolanduoni 6y ago
  It's also worth noting that although modern C/C++ has the `restrict` keyword, compilers for those languages are generally worse at actually using that information. For example, there's been a long running series of LLVM bugs that has (several times) required Rust to stop emitting that metadata because it would actually miscompile fairly simple vector operations that used `restrict`[1]. I'm hopeful that Flang (the Fortran LLVM compiler) will shake most of those out, since there's a large body of Fortran code that relies on good aliasing optimizations. [1]: https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878
  - saagarjha 6y ago
    Just C. The various “restrict equivalents” in C++ are non-standard.
ForHackernews 6y ago
Fortran is crazy fast and the standard language in many scientific domains where performance matters.
gspr 6y ago
> The question is why in 2020 R still uses a Fortran compiler? You will find that almost any scientific codebase of any size includes or relies on at least some Fortran code.
deleted 6y ago
[deleted]

The question is why in 2020 R still uses a Fortran compiler?

by Thaxll 6y ago

The question is why in 2020 R still uses a Fortran compiler?

_Wintermute 6y ago

Because it's R, it doesn't even have 64 bit integers yet.

rodonn 6y ago
It does with the bit64 package, but agree that I wish it was directly supported.

anbende 6y ago

This is answered in the article. Chunks of R are written in Fortran 90, which can’t be converted to C easily right now. You might ask why it’s written in Fortran at all. Probably has something to do with its history coming out of the S language at Bell labs in the 70s and 80s.

mmrezaie 6y ago

Fortran is domninant in HPC (Maybe not dominant, but there are a lot of software in HPC written in Fortran). R uses some performance oriented libraries which most likely implemented in Fortran.

uberman 6y ago

Fortan is berserkly fast.

bregma 6y ago

I'm sure someone will come along with a Rust rewrite any day now.

mike_ivanov 6y ago
I admire your sense of humor.

gh02t 6y ago

Tons of software are still using Fortran in the scientific/numerical world. NumPy and SciPy, for example, also make extremely heavy use of Fortran. As would many things that rely on BLAS/LAPACK. It's not just legacy code, either... Fortran is still very active in its own little niche in the numerical world.

danpalmer 6y ago
Yep, I think the issue with R is that they're using a customised version of BLAS/LAPACK – Python has been running these things on Raspberry Pis for ages now, I suspect using a more standard implementation.
- em500 6y ago
  No, the issues are different, please read the article. R also runs fine on ARM64 linux. But macOS is not linux, as mentioned in the article it has a different ABI and no free Fortran 90 compiler is available yet. The other issue is that R distinguishes between NA values and NaN values (NumPy doesn't), which are propagated differently on ARM64.
- gh02t 6y ago
  Based on the article I don't think those are the problem. I think the new Apple silicon is distinct enough that it needs a bit of porting effort to get a Fortran compiler running, along with the issue of quirks in handling NaN payloads and some other (seemingly rather minor) differences.

ryukafalz 6y ago

If it works well, why change it?

geofft 6y ago

Fortran is the standard implementation language for scientific computing in 2020. Try compiling NumPy and SciPy from source sometime.

baron_harkonnen 6y ago

Fortran is still a foundation of many important libraries for numeric computing. A fairly large number of implementations of BLAS are written in Fortran (including the reference implementation), LAPACK is written in Fortran. One of the first domains solved by programming was efficient implementations of common linear algebra computations. Fortran was the original language of choice for many of those projects. When you care about absolutely optimal performance for these computations you're not going to mess with fined tuned code that has been slowly tweaked and improved for over 50 years.

pdpi 6y ago

If I recall correctly, C and C++ allow some types of pointer aliasing that fortran forbids. If you're reading from one buffer and writing to another, those buffers can overlap in C or C++, but can't in fortran, so a fortran compiler is allowed more leeway with the way instructions are ordered (and maybe elided? Not sure). In compute-intensive workloads, every little bit helps.

rlkf 6y ago
Correct. Back in the days, it used to be that you could run Fortran 77 code through f2c and then compile with gcc using the assume-no-aliasing option, and you would get roughly the same performance as if you compiled with f77.
johncolanduoni 6y ago
It's also worth noting that although modern C/C++ has the `restrict` keyword, compilers for those languages are generally worse at actually using that information. For example, there's been a long running series of LLVM bugs that has (several times) required Rust to stop emitting that metadata because it would actually miscompile fairly simple vector operations that used `restrict`[1]. I'm hopeful that Flang (the Fortran LLVM compiler) will shake most of those out, since there's a large body of Fortran code that relies on good aliasing optimizations. [1]: https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878
- saagarjha 6y ago
  Just C. The various “restrict equivalents” in C++ are non-standard.

ForHackernews 6y ago

Fortran is crazy fast and the standard language in many scientific domains where performance matters.

gspr 6y ago

> The question is why in 2020 R still uses a Fortran compiler? You will find that almost any scientific codebase of any size includes or relies on at least some Fortran code.

deleted 6y ago

[deleted]