Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Fortran

arxiv.org

Post reply on HN
Print view View original

81–90 of 113 posts

Re: The State of Fortran

#81

Post by sam_bristow »

denisrosset wrote: post #75
bayindirh wrote: post #73

Earlier quoted context omitted.

HPC administrator, researcher and scientific software developer here. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. Moreover, te…

> The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account. I'm currently teaching modern scientific Python programming, if that's a thing. You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic? I was thinking of dividing academic c…

Maybe add a fourth category.

- Petrified: code that's set in stone and everyone's to scared to touch in because "it works, but God knows how".

Re: The State of Fortran

#82

Post by yiyus »

denisrosset wrote: post #75
bayindirh wrote: post #73

Earlier quoted context omitted.

HPC administrator, researcher and scientific software developer here. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. Moreover, te…

> The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account. I'm currently teaching modern scientific Python programming, if that's a thing. You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic? I was thinking of dividing academic c…

Stage 3 does not always happen. There are a few remarkable counterexamples, but most research software does not usually finish taking the form a product.

In my experience, what happens is that some prototype works quite well and gets used in the next project. But the next project is building a new prototype, not improving the previous one. After a few projects, the person who wrote that first prototype already left the department, but there are people who depend on it to get results. If enough time passes, you will have some piece of legacy code that very few people can understand.

The problem with academia is that, while the prototype is an excellent topic for an article, the real product, a maintained (and maintainable) software project, is not. And getting funding in academia to do something of no academic interest (ie. that cannot be turned into a paper) is very difficult. If the software is of no interest to some industrial partner willing to spend money, that code will just keep moving between the USB drives of PhD students, probably branching into slightly different versions, until someone is brave enough to start working in a new prototype and the cycle starts again.

Re: The State of Fortran

#83

Post by necheffa »

pjmlp wrote: post #61
necheffa wrote: post #51

Earlier quoted context omitted.

When C99 introduced the restrict keyword this argument fell apart. But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring. Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a…

No it didn't, it only introduced yet another source of UB, when C "experts" forget to use it the way ISO C rightfully expects.

You seem to be operating under the assumption that the Fortran compiler will catch pointer aliasing. In fact major implementations of Fortran do not (for technical reasons).

So the standard just says "don't do it, LOL" but then you are able to write Fortran violating this. Which is how you end up with bugs that go away when you switch optimization levels.

Re: The State of Fortran

#84

Post by necheffa »

dralley wrote: post #59
necheffa wrote: post #51

Earlier quoted context omitted.

When C99 introduced the restrict keyword this argument fell apart. But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring. Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a…

> When C99 introduced the restrict keyword this argument fell apart. 1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful. 2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.

Restrict is used where it matters.

Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.

Re: The State of Fortran

#85

Post by zozbot234 »

necheffa wrote: post #84
dralley wrote: post #59

Earlier quoted context omitted.

> When C99 introduced the restrict keyword this argument fell apart. 1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful. 2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.

Restrict is used where it matters. Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.

AIUI, the only language in common use that has comprehensive static checks for their equivalent to 'restrict' is Rust. Not coincidentally, there's quite a bit of interest in Rust adoption for numerics-heavy and scientific codes, the traditional preserve of FORTRAN.

Re: The State of Fortran

#86

Post by freemint »

_0w8t wrote: post #8
hatmatrix wrote: post #5

Modern Fortran is beautiful and I love coding in it. However, my understanding is that its main focus is on array computations. Now with hierarchical data structures and graphs becoming ever pervasive, I wonder if Fortran will ever try to compete in this space (when these higher-order concepts are integrated into domains of Fortran's past dominance in numerical simulation).

Hierarchical data structures are bad for CPU caches, see, for example, references in [1] how various data-oriented programming techniques try to avoid them. From that point of view Fortran may be even more relevant for high-performance computing now than even 10 years ago. [1] https://en.m.wikipedia.org/wiki/Data-oriented_design

B-Trees are very much not bad for CPU caches,neither are tries. Generalizations like this are harmful.

Re: The State of Fortran

#87

Post by GuB-42 »

throwawaybutwhy wrote: post #2

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant…

I know that modern Fortran is a thing but from my limited experience, it is being phased out. I work for an aeronautics company that has a lot of Fortran code: flight models, material calculations, etc... Some of it is maintained but I didn't see any new Fortran project, and most of the legacy Fortran code have been replaced by C++, Java, etc... as well as more specific tools like SCADE (which generates C code).

Same thing for ADA.

Re: The State of Fortran

#88

Post by leephillips »

cycomanic wrote: post #74
leephillips wrote: post #33

Earlier quoted context omitted.

Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.

I don't think Julia belongs into the same list as C++, C and Fortran. It is true that for some algorithms it is almost the same speed as C++ out of the box, but for many others it is still factors of 10s or 100s of. Also it often requires significant tweaking to get to it's best performance (e.g. don't use abstract types), so it is almost like saying Python is the a fast language, because you can use Cython or Pythra…

I was talking about reality: https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl...

Nothing overstated; just the circumstance in the real world that these four languages are the only ones used in the most demanding HPC.

C and Fortran are also not as fast as they could be if you use them incorrectly. Using concrete types is not “significant tweaking”.

Re: The State of Fortran

#89

Post by teleforce »

socialdemocrat wrote: post #69
throwawaybutwhy wrote: post #2

Please note there's been some uptick in the intensity of discussion on generics lately [0]. Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics. For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant…

Fortran has certainly been very important but now people are building climate models faster in Julia and with better performance. Fortran used to be the only option for high performance numerical computing but that is no longer the case. For instance preliminary performance tests of BLAS rebuilt for Julia shows higher performance than the Fortran variants which have been tuned for decades. Part of the reason Julia ca…

Glad to see Julia is catching up. D language has beaten Fortran based BLAS library in the performance metrics for more than five years now [1].

[1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:

http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

Re: The State of Fortran

#90

Post by adgjlsfhk1 »

cycomanic wrote: post #74
leephillips wrote: post #33

Earlier quoted context omitted.

Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.

I don't think Julia belongs into the same list as C++, C and Fortran. It is true that for some algorithms it is almost the same speed as C++ out of the box, but for many others it is still factors of 10s or 100s of. Also it often requires significant tweaking to get to it's best performance (e.g. don't use abstract types), so it is almost like saying Python is the a fast language, because you can use Cython or Pythra…

this is just false. you can not find reasonably well written Julia code that runs 10x slower than equivalent fortran.
Post reply on HN