AMD Developing Next-Gen Fortran Compiler Based On Flang, Optimized For AMD GPUs

[Svyatko]

But everything that has a beginning has also an end. Isn't Fortran slowly faiding away? Are these corporations and scientists planning to run old fortran code for the next 150 years?

Fortran holds #8 in TIOBE Index for Nov 2024:

https://www.tiobe.com/tiobe-index/

https://www.tiobe.com/tiobe-index/fortran/

Great rise during last 2 years.
Take care of your future - learn Fortran!

[Svyatko]

AMD's repo:

https://repo.radeon.com/rocm/misc/flang/

Yes! Python (compiled) can be pretty fast when the mathematical work is done within well-optimized libraries (such as numpy).

https://stackoverflow.com/questions/33723771/how-can-numpy-be-so-much-faster-than-my-fortran-routine

The numpy is faster because you wrote much more efficient code in python (and much of the numpy backend is written in optimized Fortran and C) and terribly inefficient code in Fortran.

Pure Python can be 10x - 100x times slower than Fortran/C/C++.

[rickst29]

AMD's repo:

https://repo.radeon.com/rocm/misc/flang/

https://stackoverflow.com/questions/33723771/how-can-numpy-be-so-much-faster-than-my-fortran-routine

Pure Python can be 10x - 100x times slower than Fortran/C/C++.

We agree that PYTHON run as interpreted code, and without using support libraries (such as numpy) will be vastly slower with number crunching. But 'HPC' projects should always be built to use those libraries, and they should also be compiled after debugging. I'll stand by my guess that Python will become more widely used over time.

[Old Grouch]

We agree that PYTHON run as interpreted code, and without using support libraries (such as numpy) will be vastly slower with number crunching. But 'HPC' projects should always be built to use those libraries, and they should also be compiled after debugging. I'll stand by my guess that Python will become more widely used over time.

Python as 'glue' holding together the libraries written in Fortran is what happens now. It appears to be a reasonably good model. Python obviously won't replace compiled Fortran, but allows simple 'front-end' application development. As I said earlier, the value in Fortran is the battle-tested libraries for things like numerical simulations. There's little point in re-inventing a perfectly good wheel in a new language, badly - unless the new language offers significant benefits over and above Fortran for the things that Fortran is already very, very good at.
I'm unlikely to write a GUI in Fortran, but I do know of business applications that were written in Fortran calling screen-handling (80x24, not bitmapped) libraries - that have been in use in industry for over 30 years. I would not recommend that approach now, but it was, at the very least, workable. Oddly enough, several attempts were made to replace the applications with more 'modern' approaches, all of which failed as they required far more machine resources to achieve the same tasks.

I certainly don't think that Fortran is the best tool for all programming jobs. Far from it. But in cases where Fortran is doing what it is good at (outlined in other people's postings above) it is hard to beat. There is a huge amount of work that has gone into the scientific and technical libraries, and replicating even part of that legacy would take a lot of time and money, so it is difficult to make a case for replacing them that generates the necessary payback. It is interesting to speculate on what might offer such a payback.