What stopped me a while ago was the availability of good free compilers. (the appeal is you could be faster than C for numerical code in Fortran, but I remember vaguely these compilers then would not be cheap)
Indeed. Intel Fortran is generally considered one of the best. It was not cheap, but it is now available for free. In general I think there is a huge opportunity for new compilers, and I have started one such effort myself: https://lfortran.org.
I often nowadays find GNU GFortran the same speed or faster than Intel Fortan for FEM/CFD codes, while 10-15 years ago Intel Fortan was 10-20% faster in general. So these days I typically just recommend to go with GFortan which is easily available on most platforms.
And not only on such codes. I've posted variations on this before:
In my experience GNU Fortran was always competitive with proprietary compilers at around the 20% level on average once the scheduling was sorted for a new architecture. That's from the times I could try SPARC SunOS and GNU/Linux, MIPS/Irix, Alpha/Tru64(?), RS6000/AIX, and x86 GNU/Linux. (I don't know about the times between those and Opteron.)
I don't have the numbers to hand, but it's at that level on the Polyhedron benchmarks relative to Ifort on SKX with roughly equivalent options. I think it was twice as fast on one case and basically only lost out badly where it unfortunately doesn't use vectorized maths routines for a couple of cases unusually dominated by them, whereas libvecm would be used for C. GNU Fortran is also surprisingly more reliable than Ifort, but has the bizarre mystique that had me ordered to use it against the advice of maintainers of the code, notwithstanding previous comparison with Ifort, and though the result crashed with the Ifort du jour -- which wasn't an immediate clincher.
I don't remember the numbers relative to XLF on POWER, but they were respectable, and I don't have access to the proprietary Arm compiler.
Anyhow, typical HPC run times are relatively insensitive to code generation compared with MPI (especially collectives), and typically aren't even reproducible below the 10% level. [Broad picture, mileage varies, measure and understand, etc.]
I've seen a similar change in recent years. 10 years ago Intel Fortran was usually faster, at least 20%. Good 20%. GFortran seems to have caught up a lot.
For anyone doing HPC work and hasn't tried GFortran >=10, I highly suggest giving it a go. We switched to it for the arm64 improvements, but surprisingly also found a 20% speedup on the x86-64 target. My best guess is that it's a combination of IPO and autovec enhancements.
Profiling and -fopt-info should tell you why. (If you care about speed, use them anyway!) I'd be surprised if it's vectorization improvements, other than a specific bug fix.
The main advantage usually quoted over C is the optimization opportunities from the storage association rules, in particular. GCC got the alias analysis for that as far back as the egcs version. (The flame war preceding egcs actually arose from the GNU maintainer refusing to incorporate the contributed patch for reasons I don't recall.)