A talk from the Large-scale parallel session at RSECon2022.
Details: virtual.oxfordabstracts.com/#...
Slides: d3ijlhudpq9yjw.cloudfront.net...
=====
Extra Q&A
Q: Can you move past shared memory parallelism? Any mature examples of rust+MPI?
A: There’s a crate for MPI: crates.io/crates/mpi.
Q: Why did you go for Rust rather than existing radiative transfer libraries built with C/C++?
A: We needed to change fundamental parts of the simulation (mainly scattering and surface interactions) that are deeply ingrained in the code. Overall, it was easier to create our own library than edit a pre-existing codebase that only partially suited our needs. Essentially, we needed more flexibility and control than an existing library could have feasibly provided. Also, we needed to produce a simulation and parameterisation that was fast enough to run on a clinician's laptop within an appointment time (~45min).
Q: Is there a payoff with the compiler being so strict that means you very rarely get runtime errors?
A: Absolutely! That is the aim with Rust, most (if not all) of the debugging is done at compile stage rather than runtime.
Q: Does rust have a use in HPC?
A: Yes. There is work looking into this, especially with rayon allowing openMP parallelisation. Data races and memory errors are notoriously difficult to deal with in HPC systems, while Rust doesn't protect against everything its memory model defends against such bugs.
Q: Is cargo package manager as good as it sounds? With semver promises etc? Or is it not that useful for scientific code?
A: Cargo package manager is very good! Semver is a big help - in our experience authors respect it. It is a huge help to all codebases looking to work with external libraries.
Q: Were there any obvious gaps in array (operation) support?
A: Nope. The standard library supports standard (one dimensional) arrays. Crates like Ndarray provide excellent support for multi-dimensional arrays (and is like Python's ndarray library).
Q: If you have to know about memory etc. for doing research where you don’t know the desired output. Would you start it in rust or do it in something like Python and then translate it to rust?
A: I'd recommend prototyping things quickly and flexibly in Python. Then, when you have an architecture designed, write robust, rigid and high-performance code in Rust.
Q: Will the Rust developers support and maintain it in the long-term?
A: Hopefully! It's not going to replace C/C++ anytime soon, because those languages are backwards compatible over anything else - and they've proven themselves to be stable with time (although increasingly bloated and ugly!) Writing code that you want to be compiled in 40+ years needs to be done in those languages.
If you don't need your code to last 20 years, but you want to write good clean high-performance memory-safe code, write it in Rust.
In a couple of decades hopefully, we'll have a newer generation of languages which we'll want to write in.
=====
Abstract: Rust is an open-source project that strives to solve issues from C/C++: memory errors and concurrent programming. Memory-safety and thread-safety are guaranteed and thus eliminate many bugs at compile-time. These qualities make Rust an excellent choice for writing scientific code, despite not being a popular option currently.
In this talk we will discuss the benefits (and drawbacks) of using Rust and our experiences with scientific programming in Rust including developing a Monte Carlo code for cancer research. We hope that this encourages discussion around broader applications for this relatively new language and helps to increase its use in scientific programming.
=====
0:00 Chair introduction
0:22 Talk
18:40 Q&A
25 июл 2024
