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

51–60 of 113 posts

Re: The State of Fortran

#51

Post by necheffa »

mkoubaa wrote: post #44
necheffa wrote: post #15

Earlier quoted context omitted.

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a pray…

The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more. What you end up with is a language with a reputation for being faster for computation

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 balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.

Re: The State of Fortran

#52

Post by adgjlsfhk1 »

ImprovedSilence wrote: post #50
zdragnar wrote: post #13

Earlier quoted context omitted.

That's not to say the code quality is any good, only that it still runs and everyone has their reasons to avoid a rewrite. True, the fact that it is still running says something, but not overmuch about whether it would be pleasant to maintain, extend or otherwise modify.

But does “code quality” matter if all you need is a black box calculation that spits out the right answer every time, and has done so for the past 50 years? Put all the damn goto statements in there you want, as long as I don’t have to look at at, great!

If your code is performance critical, it absolutely matters. Most Fortran code is FORTRAN 77, and 2-20x slower than it could be because it was written for processors without vectorization, out of order execution, modern branch predictors, or any of the other hardware advances of the past 30 years. Modern compilers can mitigate this slightly, but the algorithms that old FORTRAN code use are fundamentally inefficient on modern hardware.

Re: The State of Fortran

#53

Post by hoofedear »

PrintStar wrote: post #31
ogogmad wrote: post #4

What kind of editor support does Fortran have? I think a language is more than just a language as such, and the surrounding environment is at least as important if not more. I've used things like Mathematica, RStudio and Matlab, as well as Java IDEs, and these make all the difference.

We maintain a commercial, Fortran-specific IDE, Simply Fortran, that ships with the GNU Fortran compiler (at least on Windows and macOS): https://simplyfortran.com It has many of the usual IDE expectations built in like autocomplete, project management, debugging, Git integration, etc. Our Windows distribution adds a few niceties like a Fortran-oriented (though basic) GUI library, a Windows-native coarray implementat…

This looks awesome!

Am.. am I about to teach myself Fortran?

Re: The State of Fortran

#54

Post by sundarurfriend »

leephillips wrote: post #40
ivan-pi wrote: post #35

Earlier quoted context omitted.

Depends on your needs. Sometimes you just need a hammer. Michael Wirth had a few comments about Julia recently: https://craftofcoding.wordpress.com/2022/03/14/why-i-have-gi...

These comments seem out of date. There hasn’t been an issue, really, with breaking code for quite a while, since 1.0. They also show a lack of understanding in some respects, for example complaining about the hello world memory usage. Running a Julia program in the usual way loads the runtime. For another take, Jack Dongarra was just awarded 2021 ACM Turing prize. He’s the creative force behind LINPACK and BLAS, and…

Some of the comments (in the original link in your parent comment) are pretty weird:

> I sometimes wish [Julia] had just appeared one day as version 1, and made periodic updates every year or three.

> Its “multi-paradigm” nature. Yeah, I know other languages have this too, but it does tend to bloat a language.

And some are just funny:

> The language is not stable, and by that I mean it seems to have a lot of bugs [links to github issues with label:bug]. You can’t really call something that has bugs stable.

Re: The State of Fortran

#55

Post by ogogmad »

adgjlsfhk1 wrote: post #52
ImprovedSilence wrote: post #50

Earlier quoted context omitted.

But does “code quality” matter if all you need is a black box calculation that spits out the right answer every time, and has done so for the past 50 years? Put all the damn goto statements in there you want, as long as I don’t have to look at at, great!

If your code is performance critical, it absolutely matters. Most Fortran code is FORTRAN 77, and 2-20x slower than it could be because it was written for processors without vectorization, out of order execution, modern branch predictors, or any of the other hardware advances of the past 30 years. Modern compilers can mitigate this slightly, but the algorithms that old FORTRAN code use are fundamentally inefficient o…

> vectorization, out of order execution, modern branch predictors

Two out of three of those are controversial because of Spectre. https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

Re: The State of Fortran

#56

Post by leephillips »

sundarurfriend wrote: post #54
leephillips wrote: post #40

Earlier quoted context omitted.

These comments seem out of date. There hasn’t been an issue, really, with breaking code for quite a while, since 1.0. They also show a lack of understanding in some respects, for example complaining about the hello world memory usage. Running a Julia program in the usual way loads the runtime. For another take, Jack Dongarra was just awarded 2021 ACM Turing prize. He’s the creative force behind LINPACK and BLAS, and…

Some of the comments (in the original link in your parent comment) are pretty weird: > I sometimes wish [Julia] had just appeared one day as version 1, and made periodic updates every year or three. > Its “multi-paradigm” nature. Yeah, I know other languages have this too, but it does tend to bloat a language. And some are just funny: > The language is not stable, and by that I mean it seems to have a lot of bugs [li…

Yeah. Of course there are bugs, but none of them are serious. Julia is still a young language, but it’s rock solid and used in high stakes, high performance computing in industry, government, and academia. Like I said, there are only four high-level languages that can perform at this level. Julia is certainly the most advanced and interesting of these, and, yes, it’s just a lot of fun to use.

Re: The State of Fortran

#57

Post by adgjlsfhk1 »

ogogmad wrote: post #55
adgjlsfhk1 wrote: post #52

Earlier quoted context omitted.

If your code is performance critical, it absolutely matters. Most Fortran code is FORTRAN 77, and 2-20x slower than it could be because it was written for processors without vectorization, out of order execution, modern branch predictors, or any of the other hardware advances of the past 30 years. Modern compilers can mitigate this slightly, but the algorithms that old FORTRAN code use are fundamentally inefficient o…

> vectorization, out of order execution, modern branch predictors Two out of three of those are controversial because of Spectre. https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

They might be "controversial", but they still are absolutely necessary. Modern CPUs typically execute around 3 operations per clock cycle. Without OOO and speculative execution, that drops to .3 (roughly). There's a reason no one is making cpus without them for anything even performance adjacent. Also, just because Fortran code was written without knowing about them, doesn't mean they don't still happen, the only difference is that the algorithms are bad.

Re: The State of Fortran

#58

Post by agucova »

jordemort wrote: post #11

The fact that “The State of Fortran” is a paper on arXiv instead of a blog post actually says a lot about the state of Fortran.

This only speaks to the academic nature of Fortran, and there's nothing wrong about it.

Re: The State of Fortran

#59

Post by dralley »

necheffa wrote: post #51
mkoubaa wrote: post #44

Earlier quoted context omitted.

The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more. What you end up with is a language with a reputation for being faster for computation

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.

Re: The State of Fortran

#60

Post by noobermin »

necheffa wrote: post #15
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…

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a pray…

Man, why is inertia considered a bad thing? "new code is bolted on, with a prayer that nothing breaks" is literally all of software development. How many times do things break because some fool decided we need to use js framework 2022.04.07 when 2022.03.05 worked fine but new, shiny etc thus break. "Old" does not mean broken automatically, people seriously need to excise this assumption in software development because it simply isn't true.
Post reply on HN