8 ms·
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
by m_mueller 3y ago
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).
"""
- deleted 3y ago[deleted]
- iLoveOncall 3y agoThis 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.
- m_mueller 3y agoYes 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.
- sigsev_251 3y agoYou 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-matrices/ https://gustedt.wordpress.com/2014/09/08/dont-use-fake-matri...
- deleted 3y ago[deleted]
- camel-cdr 3y ago> 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)
- xmcqdpt2 3y agoThe 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.
- camel-cdr 3y agoThe 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.
- unnah 3y agoIt 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.
- Findecanor 3y agoVLAs 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.
- xmcqdpt2 3y ago
- Bostonian 3y agoIn 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.
- armchairhacker 3y agoWhat 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)
- thanatropism 3y agoI 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.)
- Thiez 3y agoCrazy to think someone would pass a single 32-bit float by reference.
- m_mueller 3y agonote: 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.
- BeetleB 3y agoUnfortunately, you cannot get the main users of Fortran to use anything other than Fortran 77.
- m_mueller 3y agoI guess it depends on the field. What I experienced in climate & weather prediction was by and large Fortran 90 codebases.
- kergonath 3y agoI 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.
- BeetleB 3y agoBased 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.
- jki275 3y agoIt'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.
- walleeee 3y agoThe 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.
- deleted 3y ago[deleted]