Hacker News Reader

Comment by kutkloon7 | Hacker News Reader

Why is it better than C(++) for this?

Historically i believe Fortran language had stronger assumptions that variables arent aliases for the same memory. This means that the compiler can be more aggressive (than e.g. C) in terms of the generated code as it doesnt have to behave correctly if e.g. memory for unrelated arrays overlap. See https://en.wikipedia.org/wiki/Pointer_aliasing

I am not sure if this performance advantage is still the case as the wikipedia page on pointer aliasing notes that C99 added a "restrict" keyword so that the C programmer can tell the C compiler where similar strong assumptions can hold.

Because for example Fortran has multi dimensional arrays as first class entities. C does not. Yes you can get the same speed in C - yes you can do the same things in C but you can do them with simpler code easier to reason about code in Fortran.

Modern Fortran is high-level enough to pass for MATLAB, has full vectorized operations support, but in many cases faster than C. What's not to like?

Because of the libraries.

You say you can get matrix libraries for C++. And you're right, you can. But with Fortran, you can get (for example) functions that will solve Hermitian matrices, which run faster than solving regular matrices. Or special routines for sparse matrices, which run faster and use less memory. Or...

And you could write every one of those in C++. But the Fortran ones have 30 years of debugging and optimization on them. They're solid. You can't get that by writing your equivalent in C++.

Because Fortran was purpose-built for manipulating array-based data while C++ is a general-purpose programming language. That means Fortran is optimized for this problem domain starting at the _grammar of the language_ while C++ can provide at best access to a locally optimized set of libraries. Those libraries might be quite good, but the comparative experience is still like trying to drive a Phillips-head screw using a flat-head screwdriver.

Because scientists already know fortran and they're too lazy to learn something else even if there would be significantly improved results.

No, because computer scientists are too lazy to create modern domain specific languages that are powerful enough for practitioners to put to effective use. :-)

Like what?

Julia, C++ with libraries, Python with Cython or Numba, etc.

You could also get much faster if most of your work is matrix multiplication if you make use of libraries like ViennaCL and a modern C++ compiler.

Both Julia and Python use Fortran code under the hood to speed up matrix multiplication. Julia comes with OpenBLAS which is partially written in Fortran, and the following page of SciPy documentation indicates that a Fortran compiler is required for some NumPy modules:

https://docs.scipy.org/doc/numpy-1.10.1/user/install.html

"To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN 77 compiler installed."

I would also say that no one in the scientific world should be writing ASM for their programs. Does that mean I'm also telling them not to use any compiled language? No.

ASM != Machine code.

That aside, you haven't explained why you think the languages you listed are better suited for scientists than Fortran. What are your issues with modern Fortran?

Modern library availability, larger pool of programmers, better compiler technologies, more features that apply to modern hardware, cleaner code, and better documentation are all present on my languages. They are not present on FORTRAN.

Numpy, Scipy and a lot of other numerical libraries use Fortran for the underlying operations along with C. Because Fortran is just faster for such operations and will continue to be. Numba is still very much alpha. Julia is still immature for production (Good language from what I hear but still very much in development).

Don't know if C++ can ever be as fast as Fortran because all fortran compilers are optimized for the architecture on which they run. (Best fortran compiler for intel cpus is by intel). As for ViennaCL I don't know much about GPU programming and its performance. Never done it. (My only exp is with Cython and Scipy stuff)

Intel also has C/C++ compilers which probably share optimizers and backend code generators with their Fortran compiler and shouldn't be worse. Ditto for 3rd party commercial vendors like PGI.

And, BTW, I have seen a case where PGI vastly outperformed GCC on the same code. So compilers matter.

All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination. And all are worse performance-wise.

Julia is regarded as the modern replacement for Fortran, but it isn't quite there yet.

The major problem with Fortran is that there is (sadly) nearly no documentation on modern idioms, and occasionally you have to dive in legacy code, which can be... scary, to say the least. Otherwise, it was upgraded really well, without losing performance.

> All these languages, except Julia, are much _worse_ syntactically than modern Fortran. Especially C++, which is a clusterfuck beyond the widest possible imagination.

There is some C++ code that is very bad out there but most C++ code maintained by normal people is passable. When I use it I use it as C with references.

> And all are worse performance-wise.

You are incorrect just by the facts of the situation [0][1][2]. This lie has stuck around so lazy people can pat themselves on the back for being lazy. "Yay we did it! We found the best language every! We don't need to learn anything new or update anything!".

The truth is a modern C/C++ compiler like GCC or clang/LLVM can generate far more efficient code than Intel's FORTAN compiler. Not only that but you have access to more performance and scalability libraries when you're not using the programming language equivalent of Latin. You're never going to get out of the MPI ditch that scientists have dug for themselves in a museum piece like FORTRAN. There will be no good abstractions, no well planned libraries, no in language support for newer hardware.

FORTRAN is going to be stuck in the 70s and 90s.

Languages like C++, Python's libraries, Julia, and other languages (like D/Go/etc) are going to evolve as industry needs them to. As we start being able to use less and less of the our computers abilities compilers, optimizers, and libraries are going to allow us to easily pick up the slack. You can already see this things like ViennaCL. GPUs, FPGAs and other tools are coming. MPI and FORTRAN can't be the only tool in your toolbox and if you're lying to yourself and burying your head in the sand in an attempt to pretend you can then good luck to you. You're wasting your budget, the taxpayer's money, and everyone's time on the supercomputer's queue because you don't want to try something new.

But it's fine. Who cares really. FORTRAN is the only language a scientist will ever need. I mean it is the fastest (even if it isn't) and it has the best compilers (even if they aren't the best and we waste thousands and thousands of dollars of taxpayer money to get them) and we know it and that's all that matters. Who cares about broader impact, portability, and future proofing.

[0] - http://benchmarksgame.alioth.debian.org/u64q/fortran.html

[1] - https://julialang.org/benchmarks/

[2] - http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

is gfortran that much slower than Intel's compiler that they didn't bother to benchmark it?

Reply on news.ycombinator.com