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

61–70 of 113 posts

Re: The State of Fortran

#61

Post by pjmlp »

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…

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.

Re: The State of Fortran

#62

Post by noobermin »

RandomWorker wrote: post #49
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’s worth the nuclear power plant I worked at ran mostly on LabView. We compiled the code on PCs onto dedicated LabView boxes. No Fortran was ever used.

Now, as someone with experience with labview that is a horrifying thought...

Re: The State of Fortran

#63

Post by pjmlp »

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…

When I was at CERN, the surviving Fortran code that I related to, was decent Fortran 95.

Re: The State of Fortran

#64

Post by noobermin »

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).

Honestly, it really shouldn't, at least IMO. Where may be once it was used for other things, today it's essentially a DSL of some sort for the numerical computations you specify. It doesn't need to be used for a game engine (game engines can go ahead and call fortran code as they might).

Re: The State of Fortran

#65

Post by kergonath »

ratboy666 wrote: post #38
kergonath wrote: post #19

Earlier quoted context omitted.

I tend to use TextMate on Mac or SublimeText on other platforms. Fortran also is usually very close to C, and most standard debuggers like ten or lldb (even when LLVM had no Fortran front-end) can be used without problems. It’s a bit barebones compared to recent IDEs, sure. What I would like in particular is better refactoring and static analysis tools (though the lack of the latter is mitigated by the strong type sy…

But... Matlab was originally written in FORTRAN ("easy access to... LINPACK and EISPACK..."). Written by Cleve Moler, distributed by Jim Kweeder. May 25, 1982. 7852 lines of FORTRAN 66 (for the version I have). "With proper use of overlays, it is possible run the system on a minicomputer with only 32K bytes of memory." -- Cleve Moler Fred Weigel

Sure, a lot of Matlab is in Fortran (and a lot of other software as well, though you would not know from the outside), but you don’t write in Fortran when using Matlab.

Re: The State of Fortran

#66

Post by hilbert42 »

noobermin wrote: post #62
RandomWorker wrote: post #49

Earlier quoted context omitted.

For what it’s worth the nuclear power plant I worked at ran mostly on LabView. We compiled the code on PCs onto dedicated LabView boxes. No Fortran was ever used.

Now, as someone with experience with labview that is a horrifying thought...

I'd absolutely agree, it's truly worrying.

I say that as someone who has worked in nuclear safeguards.

Re: The State of Fortran

#67

Post by wallfacer120 »

noobermin wrote: post #60
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…

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 becaus…

I strongly suspect there is an preference-oscillation in coding languages that is similar to the one found in broader culture between serif and sans-serif fonts. Can't fix on what it would be though?

Re: The State of Fortran

#68

Post by cube00 »

zozbot234 wrote: post #21
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.

Last I checked, you had to write out your program on paper, using the special Fortran coding forms. Then you just gave the written out forms to someone who would type out your codes at a keypunch and give you a deck of freshly punched cards, or you could take care of it yourself.

These two training videos from the Bell Labs Computing Centre are a very interesting insight into what it was like.

Part 1 https://www.youtube.com/watch?v=HMYiktO0D64

Part 2 https://www.youtube.com/watch?v=V9aVOIuKVUc

Re: The State of Fortran

#69

Post by socialdemocrat »

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 can do this is due to support for parametrized types and JIT compilation which I can make it possible to in-line a lot of code which you cannot inline with AOT compilation.

Re: The State of Fortran

#70

Post by ogogmad »

milancurcic wrote: post #48
ogogmad wrote: post #3

Are things like higher order functions and closures relevant features for Fortran programmers? This is an open-ended question. [edit] Just to be clear, I don't think Fortran has these.

It's limited. You can pass functions as arguments to other functions. You can't return a function as a function result.

I was asking whether these are worth having in a future version.
Post reply on HN