Comment by m_mueller | Hacker News Reader

Comment by m_mueller | Hacker News Reader

Quoting what I wrote a couple of months ago in another thread, regarding the advantages of (Modern) Fortran vs. C/C++:

"""

Just an example on how to declaring a couple of input float pointers in a fully optimized way, avoiding aliases and declaring it readonly (if I remember correctly, it's been a few years:

Fortran:

    real(32), intent(in) :: foo, bar, baz

C:

    const float *const restrict foo
    const float *const restrict bar
    const float *const restrict baz

of course what happens then is that people will do a typedef and hide it away... and then every application invents its own standards and becomes harder to interoperate on a common basis. in Fortran it's just baked in. Another example: multidimensional arrays. In C/C++ it either doesn't exist, is not flat memory space (and thus for grid applications very slow), or is an external library (again restricting your interop with other scientific applications). In Fortran:

    integer, parameter :: n = 10, m = 5
    real(32), dimension(n, m) :: foo, bar, baz

Again, reasonably simple to understand, and it's already reasonably close to what you want - there are still ways to make it better like memory alignment, but I'd claim you're already at 80% of optimal as long as you understand memory layout and its impact on caching when accessing it (which is usually a very low hanging fruit, you just have to know which order to loop it over).

"""

You don't really have to use a pointer in modern C. The recommended practice is to use variably modified types these days[1].

[1]: https://gustedt.wordpress.com/2014/09/08/dont-use-fake-matri...

What about in Rust?

    foo: Box<f32> // or &’a f32 or &f32 if borrowing

Multidimensional arrays:

    foo: [[f32; M]; N]

(These have flat storage. However I do assume most Rust devs use external libraries, which also have flat storage but the incompatibility issues you mentioned)

I wish the Python<->Rust interop story was a little better. I learned to write some C++ for an embedded thing (smart flashlight, story for another time) and immediately started writing the Python extensions I struggled to write with Rust.

(The average data science/ML-ish person encounters/figures out custom algorithms maybe three or four times a year, and three of these are fast enough with vectorization contortions. I've had two cases that were recursive and 25X faster in $fast_lang than I could possibly make in Python.)

Crazy to think someone would pass a single 32-bit float by reference.

note: it was just an example. but in the end from a performance optimization standpoint it is a lot about what information you want to give to help the compiler along at doing its best job. with many compilers/languages that tends to be value semantics; however specifically in Fortran, which defaults to immutable reference semantics, reference types tend to be very straightforward to work together with the machine, avoid additional and keep functions inline-able. Overall from my experience this creates a more performant baseline when non-engineers work with it.

In Fortran it is suggested that you define a module with a parameter specifying the working precision of real variables, perhaps with

   module kind_mod
   use iso_fortran_env
   integer, parameter :: wp = real64 ! or real32 or real128
   end module kind_mod

   use kind_mod
   real(kind=wp) :: a, b, c

Then you change your entire program to use single, double or quadruple precision by changing the line that sets wp.

This is such a disingenuous exemple.

You declare all 3 variables on the same line in Fortran but not in C despite it being supported.

In any case, syntaxic sugar is irrelevant.

Yes I do, because in C you do have to repeat pointer declarations and their modifiers per variable - there is no clean way to separate the variable name declarations from their properties

Edit: disagree also on sugar being irrelevant. It’s all about where you guide non engineers towards when they learn it. Domain scientists can be astonishingly productive in Fortran thanks to that - to achieve the same in e.g. C++ takes a lot more effort in training and establishing best practices, libraries etc.

C2x (or any gnu dialect):

    typeof(const float *const restrict) foo, bar, baz;

But yes FORTRAN got the defaults correct for it's applications.

Thanks! Actually wasn't aware of this. Still, not exactly something you want to repeat in every function declaration.

Unfortunately, you cannot get the main users of Fortran to use anything other than Fortran 77.

I guess it depends on the field. What I experienced in climate & weather prediction was by and large Fortran 90 codebases.

I don’t think this is true. All the people who got stuck in the 1980s retired. The people I know who write in-house Fortran codes are somewhere in F2003 (all of the multidimensional arrays and allocatable variables niceness, some objects and QoL improvements from F2008/2018). None of them still writes in fixed form, and most of them never did at any point in their careers.

Based on the comments, it seems it is very field dependent. My experience is mostly from physics/electromagnetics. All my fellow grad students learned Fortran 77 as that's what the code bases were in. I should ping the few that are professors to see if they're forcing their students to behave likewise.

It's absolutely true in some domains. I've got several million lines of F77 and no money to update it and an absolute mandate not to change a single compiler flag.

The active Fortran projects I have seen (hydrology) are mostly f90+. That said, they were rewritten over years of dedicated effort and could easily have languished in original form had the federal funding landscape looked different in recent decades.

> Another example: multidimensional arrays.

It depends on what you mean by that, but VMTs are pretty much that.

    size_t n = 10, m = 5;
    typeof((*float)[n]) foo, var, baz;

You still need to initialize those, but that's also quite easy, e.g. to allocate it on the heap: foo = malloc(m*sizeof *foo)

The C equivalent for Fortran stack-allocated arrays is Variable Length Arrays (VLA) which are (afaik) a GNU extension which is usually considered bad.

They are awesome in Fortran because it means that I can (for example) write a function that takes arrays of size N and stack allocate temporaries of size N on entry. I can pass those to other functions etc and they will be freed automatically when I return to my caller. It's actually a really nice feature.

The reason VLAs are considered bad is because they stack allocate non fixed size buffers and the stack is limited. The argument goes that one might as well use a fixed size if you need to use enforce upper bound anyways.

It is possible to heap allocate a VLA too, although the syntax is a bit more cumbersome with pointer access. But it does allow you to pass dynamically sized multi-dimensional arrays to functions and access them with array indexing notation.

VLAs on the stack were introduced in C99. They became optional in C11. They are a GNU extension for C++, though.

BTW, MSVC never supported C99 or VLAs. Recent versions support C11.

Thanks, didn't know they were in the standard (for a while anyway).

Reply on news.ycombinator.com