[phreeza]

I understood the comment as saying the fortran code maybe used some sort of inefficient numerical scheme and/or some inaccurate approximations? Doesn't seem completely outlandish that more modern methods could help there? Of course fortran is not a problem in itself, you are right.

[gauge_field]

In addition to the capabilities of language, usually it depends also on the ecosystem than the language itself (unless you want to write the entire algorithm by yourself for some reason). This is especially true if the algorithms used in the project are well-studied and the efficient implementations are provided. That is probably the reason why using modern/popular tool/language will more likely to perform better.

One of the most prominent example of this gemm. Usually, the state of the art code base on gemm are written C/C++, in terms of implementations in academic papers/github, see e.g. openblas, blis, blasfeo. The same situation applies to CUDA code or accelerator agnostic code e.g. using MLIR. I think it's more a result of how the language allowed people to create an ecosystem + ecosystem created by the people using the language. Sure, you can write Fortran, but if I see more tooling and more other people benchmarking, I can be more sure that the software will be tested more and higher performance etc. For instance, if you look at benchmarks-game, the top results are C/C++/Rust. Instead of making claims like this code is not wrong/right, we should look at the concrete/quantitative results like benchmarking/number of users. As another example, you can check blasfeo paper where they used C code.

I would welcome Fortran benchmarking results. But, I just dont see it being tested enough (in open source/papers/benchmarks) to prefer it over C/C++/Rust.

There are other consequences of this networking issue: availability of docs, finding an question and answer for a problem that you experienced.