Hacker News Reader

Comment by otterdude | Hacker News Reader

Fortran while historically important doesn't really seem like a good choice today.

I worked with a proprietary jet engine analysis software suite written in Fortran 77 and It felt very primitive, albeit fast.

Today I feel like C is a much better choice for speed and readability.

If you really need the fastest performance I dont think Fortran gives that much of an advantage writing assembly.

View on HN

With vector machines, Fortran yielded (much) faster code because (a) there was a whole lot of work on preprocessors for "dusty deck" code and (b) the lack of pointers and their overlap let the compilers do their stuff. C code needed a lot of #pragma's to let it know that some pointers didn't overlap and so could be optimized.

We found it best to to the front-end and I/O of the code in C and the compute in Fortran. Fastest calculations especially with those tailored libraries.

C allowed pointer aliasing, so you always have to refresh reads incase a pojnter modified the value. With any loop, that is just more reads to update dependancies every cycle. When not aliased, you cache value in register. Much later C introduced “restrict” keyword to match fortran performance code. c++ is still fighting this by insisting you work with different types, hence by default you dont get aliasing but that doesnt cover 100% of scenarios.

Maybe we get restrict in C++35

Fortran certainly has its place, but if you really need to squeeze every bit of performance out of a machine I think assembly might be better and not much harder.

Fortran invented array-based programming, which arguably numpy advanced and now Julia finally perfected

Fortran had arrays since the beginning, but it wasn't really for "array-based programming" except in a trivial sense, since expressions could not produce arrays. APL is the language that invented first-class arrays, and is far more advanced at it than most of its successors, particularly including NumPy.

Modern Fortran has pretty serviceable support for array programming.

> which arguably numpy advanced and now Julia finally perfected

cough S/R cough.

Like, both Numpy and S/R evolved as an interface over Fortran programs for matrix manipulation but S (even R, maybe) signficantly predates Numpy.

Hard disagree that julai perfected arrays. I love Julia but even compared with old with old “array programming lenguaje” like APL not even mentioning newer ones like BQN. Julia array still seem a less expressive than one might hope.

There’s also an under explored area of compile time Shape Type checking which there has been interesting advancements in the Rust space like https://github.com/JErnestoMtz/rapl

There’s also an under explored area of compile time Shape checking, that might open up a new era in array. There has been interesting advancements in the Rust space like https://github.com/JErnestoMtz/rapl or https://github.com/chelsea0x3b/dfdx

Reply on news.ycombinator.com