[dgellow]

I'm not familiar at all with the world of high performance scientific computing. Are C++, Rust, Nim, Zig, & co. even remotely considered as potential candidates in the future, or is it really only C and Fortran with no expectation to see much changes? Just curious.

[cbkeller]

C++ certainly, and I would not be surprised to see Rust in the near future.

I have not seen anyone use Nim or Zig yet. There are also some special-purpose languages like Fortress (apparently now defunct), Coarray-Fortran, and Chapel, though none seems to have achieved too much market-share.

Personally I have almost entirely switched to Julia (from mostly C), which lets me do my everyday plotting / analysis / interpretation and my HPC (via MPI.jl) in the same language. Fortran definitely still has some appeal as well though.

[cema]

Also Julia. A rising star, with a vibrant community and ongoing improvements such as performance optimization

[dgellow]

Wow, Julia is already good enough to replace C in that context? I didn't know.

[cbkeller]

Well, I'd say I'm generally at the shallow end of the HPC pool, and also in a field that's relatively new to HPC in general so there aren't a ton of established community codes to draw upon. Consequently, I'm willing to make a few mild performance tradeoffs if it means my grad students and I can iterate faster.

If you wanted to use Julia at petascale or above (like the Celeste folks), then you'd probably want to be doing that in a case where you see fundamental algorithmic improvements you could readily make over the current SOTA with a higher level, dispatch-oriented language - or else a case where you really need, say, certain types of AD or the DiffEq + ML capabilities of the SciML ecosystem (the latter of which very much depends on the level of composability that follows from the dispatch-oriented programming paradigm).

In general, my two cents on what it takes to get "good enough" performance from Julia for my sort of HPC are that you (1) embrace the dispatch-oriented paradigm and take type-stability seriously, and (2) either disable the GC and manage memory manually or else (my usual approach) allocate everything you need heap-allocated up-front, and subsequently restrict yourself to in-place methods and the stack.

MPI.jl pretty much "just works" in my usage so far (just have to point it towards your cluster's OpenMPI/MPICH) and things like LoopVectorization.jl are great for properly filling up your vector registers with minimal programmer effort.

[hpb42]

C++ is widely used for High Energy Physics. The ROOT framework [0], developed at CERN, is mostly C++.

I'd be tempted to say that Rust could be used as well, but the equivalent of MPI and OpenMP for Rust is still not as fast as in C++/C/Fortran.[2] That's easy to understand: there are decades of investment in MPI/OpenMP for C/C++/Fortran, and Rust is not there yet.

Also, in some cases where high throughput is needed, languages with garbage collector are not suited. In this scenario, deterministic execution time and deterministic latency are very important. Not directly related to HPC, but Discord migrated from Go to Rust for this reason[2].

[0] https://root.cern/

[1] https://github.com/trsupradeep/15618-project

[2] https://blog.discord.com/why-discord-is-switching-from-go-to...

[dgellow]

Thanks, discord’s article is fascinating.

[Chemiseblanc]

C++ sees a fair amount of use and has some mature libraries written in it like the trilinos collection alongside being able to use existing C libraries. I think for other languages the limiting factor is the maturity of their linear algebra libraries and if someone has written bindings to use MPI

[IshKebab]

I haven't read the article but in my experience FORTRAN is used because a lot of really complex numerical routines were written years ago by really smart people in FORTRAN and nobody really wants to rewrite them. There are exceptions - the basic LAPACK stuff has modern alternatives (e.g. Eigen for C++, nalgebra for Rust).

But there are a ton of more specialist libraries, e.g. ARPACK that people probably aren't going to rewrite.

That said, there's a FORTRAN to C transpiler that works pretty well. I used it when I needed ARPACK and didn't want to deal with FORTRAN.