Rust on grid computing

Question

I'm looking to create Rust implementations of some small bioinformatics programs for my research. One of my main considerations is performance, and while I know that I could schedule the Rust program to run on a grid with qsub - the cluster I have access to uses Oracle's GridEngine - I'm worried that the fact that I'm not calling MPI directly will cause performance issues with the Rust program.

Will scheduling the program without using an MPI library hinder performance greatly? Should I use an MPI library in Rust, and if so, are there any known MPI libraries for Rust? I've looked for one but I haven't found anything.

Beak

If your MPI library of choice has a C interface (AFAIK most of them have), you can use that interface from Rust. It may be less convenient (or more work, if you create a convenient wrapper yourself), but it should be about as fast. – Corrie

I'm assuming that using the C library/interface for MPI would be as performant as using it in C... is this correct? Or would I possibly lose some performance when using the C lib in Rust? Ideally I could use an MPI library written in Rust but it seems that none exist. Also, in reference to the original question - if I don't use an MPI lib, will it have much effect? – Beak

The C FFI is officially intended to be as fast as a C-to-C call. I don't know if this is completely achieved yet, but if not, it should be pretty close now and even closer in the future. For the rest of your question: I don't know any MPI libraries written in Rust, and I don't know how using an MPI library vs. using qsub will affect performance. (And I don't know enough about the field to claim the latter is not answerable without much more detail.) – Corrie

Alright, thanks @delnan. I have one last question, which is subjective - do you think it would be worth it to create an MPI library in Rust from, e.g. OpenMPI source? After looking at the way Rust handles FFI, which is to treat the C functions as unsafe, I feel that it's a compromise and it would be nicer to have a direct MPI library which doesn't require the judicious use of unsafe. Also, if you want to answer the question rather than comment I will accept. – Beak

Answer 1

I have used several supercomputing facilities (I'm an astrophysicist) and have often faced the same problem: I know C/C++ very well but prefer to work with other languages.

In general, any approach other than MPI will do, but consider that often such supercomputers have heavily optimised MPI libraries, often tailored for the specific hardware integrated in the cluster. It is difficult to tell how much the performance of your Rust programs will be affected if you do not use MPI, but the safest bet is to stay with the MPI implementation provided on the cluster.

There is no performance penalty in using a Rust wrapper around a C library like a MPI library, as the bottleneck is the time needed to transfer data (e.g. via a MPI_Send) between nodes, not the negligible cost of an additional function call. (Moreover, this is not the case for Rust: there is no additional function call, as already stated above.)

However, despite the very good FFI provided by Rust, it is not going to be easy to create MPI bindings. The problem lies in the fact that MPI is not a library, but a specification. Popular MPI libraries are OpenMPI (http://www.open-mpi.org) and MPICH (http://www.mpich.org). Each of them differs slightly in the way they implement the standard, and they usually cover such differences using C preprocessor macros. Very few FFIs are able to deal with complex macros; I don't know how Rust scores here.

As an instance, I am implementing an MPI Program in Free Pascal but I am not able to use the existing MPICH bindings (http://wiki.lazarus.freepascal.org/MPICH), as the cluster I am using provides its own MPI library and I prefer to use this one for the reason stated above. I was unable to reuse MPICH bindings, as they assumed that constants like MPI_BYTE were hardcoded integer constants. But in my case they are pointers to opaque structures that seem to be created when MPI_Init is called.

Julia bindings to MPI (https://github.com/lcw/MPI.jl) solve this problem by running C and Fortran programs during the installation that generate Julia code with the correct values for such constants. See e.g. https://github.com/lcw/MPI.jl/blob/master/deps/make_f_const.f

In my case I preferred to implement a middleware, I.e., a small C library which wraps MPI calls with a more "predictable" interface. (This is more or less what the Python and Ocaml bindings do too, see https://forge.ocamlcore.org/projects/ocamlmpi/ and http://mpi4py.scipy.org.) Things are running smoothly, so far I haven't got any problem.

Atencio

Thanks! Sorry for taking so long to accept this answer. My research ended up going in a different direction so I didn't need to write any programs for my cluster in Rust, but I may revisit it as Rust nears v 1.0 and the APIs become locked. Have you used Rust in a MPI (either with OpenMPI or MPICH) setting? I'd be interested to know how it handles the issue you bring up about macros. – Beak

Nope, at the moment I'm slowly abandoning Free Pascal in favor of Nim, as it generates C programs instead of binaries like Rust. It should therefore be much easier to create bindings to "nasty" libraries such as OpenMPI. (I've not written the bindings to MPI yet, though: I am still writing some basic libraries needed for my purposes. But MPI bindings is definitely something I'll do shortly.) – Atencio

Answer 2

Will scheduling the program without using an MPI library hinder performance greatly?

There are lots of ways to carry out parallel computing. MPI is one, and as comments to your question indicate you can call MPI from Rust with a bit of gymnastics.

But there are other approaches, like the PGAS family (Chapel, OpenSHMEM, Co-array Fortran), or alternative messaging like what Charm++ uses.

MPI is "simply" providing a (very useful, highly portable, aggressively optimized) messaging abstraction, but as long as you have some way to manage the parallelism, you can run anything on a cluster.

Issykkul