Swift for HPC?

HPC applications in atmospheric and climate research are usually written in Fortran (f90) or C/C++ and optimised for maximum efficiency with the support of the respective compiler developer. In recent years, Python and R have found their way into HPC models due to their ease of use - some HPC centres even host a Jupiter notebook node (caution, wet floor due to memory leaks ;)).

This got me thinking about whether Swift would be suitable for HPC and what the trade-offs would be. Many models use openMPI for parallelisation and I think even though Swift is slower in arithmetic compared to f90, things like the cooperative concurrency model would add a lot of value and maybe even compensate for speed loss.

Does anyone have experience with using Swift for high performance computing applications and could share a thought?

3 Likes

It's really not. FLOPs are FLOPs, the language the source was written in really doesn't matter. CPUs don't have special slow FMA units that they use for Swift programs. Fortran makes some things easier to express than they are in C++ or Swift, but that's not fundamental to the language in any meaningful way.

The strengths of Fortran in HPC are familiarity, a huge existing source base, and the fact that it provides abstractions that are much more narrowly tailored for numerical programming than almost any other language does (C++ is finally sort of starting to get there, after 20+ years of effort, but it still has a lot of catching up to do).

5 Likes

Sure, but Swift (without -Ounchecked) is unambiguously slower in integer arithmetic due to overflow checking.

1 Like

Which is why &+ and friends exist. There are escape valves for all of the checks, which I would expect any serious numerical library to avail itself of when appropriate.

8 Likes

I'd say there's nothing about Swift that makes it unsuitable for HPC, but that's really beside the point. The things which dominate language selection in HPC are mostly inertia and conservatism. There's still people today in the HPC space that are only just migrating to gcc from whatever proprietary 1980s compiler they had been using, let-alone to Clang, let-alone to modern languages.

There are certainly folks that buck that trend, but alas they seem to be a small minority.

Especially when you get into the 'supercomputing' HPC subset - in the vein of Top500 etc - there's strong headwinds against change because of so many millions (or billions) of dollars being involved. There's some appetite for hardware innovation, but on the software side the mantra is often "if it isn't horribly broken then don't touch it".

None of that is meant to discourage anyone, I'm just trying to express that Swift is a perfectly good option but it's not really up to Swift.

6 Likes

any recommendations for good (linux-supporting) swift numerical/geometry libraries in 2023?

1 Like

I’ve been looking into this lately and haven’t found a single maintained project that’s cross-platform. I have a few leads around how this should work (like Nifty), but nothing concrete.

Long-term, I’m starting to think C++ interop is the solution (ie, CppCon 2023 std::linalg: Linear Algebra Coming to Standard C++ -- Mark Hoemmen : Standard C++).

Ok. In our case, (at Top500 #74) the only thing that matters is the cost of operation and the susceptibility to errors. On one side, the cost to run the models 24/7 counts a lot but also the costs to develop and maintain it are essential. The more complex the problem, the more you benefit from a well structured and safe language. Another example would be I/O. When dealing with terabytes of input and output, I think (Swifts) concurrency and threading support could save a lot of time compared to MPI implementations especially when considering changes to be made. I think it's worth giving it a shot.

2 Likes

If anyone has any tips/references on how to push Swift's performance to the limit without getting too unsafe, I would appreciate you sharing them here. E.g. stuff about array operation, memory management with Tb of data, etc.