So, I thought I would post this idea hear before posting it to the ADA RFCs repo. I’ve read and heard roomers about the DSA being potentially deprecated, if not outright removed, from the spec. Though I understand the reasoning for this (the implementations of it are probably old, if GNAT’s allowance for XDR is any indication), but if implemented properly it could be a really powerful incentive to use Ada: free multi-process/distributed/parallel execution, built right into the language. Sure, you’ve got parallel loops and blocks, but that’s not as fun as being able to say “send this process this message, on this computer all the way over here in Germany from this computer in Canada” without really having to implement much of anything. Typically if you want to do something like this you have to implement all the networking (and potentially the protocols) yourself, which can lead to a lot of boilerplate code. In languages like C++, this has resulted in libraries like OpenMP, Boost.MPI, or HPX. HPX has even gone to the trouble of (supposedly) replicating the entirety of the C++ standard library, which is not an even remotely simple thing to do, all for HPC purposes. So, I was thinking: we have all these standards that are, well, supposed to standardize distributed communication of processes across program, operating system, hardware, and even network boundaries. The ARM pretty much plays fast and loose with the implementation of the DSA, leaving a pretty significant portion of the how up to the implementor, and essentially describing something like MPI in abstract details.

And, really, when you think about it (or, at least, when I think about it), the DSA literally describes MPI to a tee. It uses different terminology, perhaps, but things like the DSA were practically what MPI was designed for. To my knowledge, MPI offers everything that the DSA requires, and then some:

• Point-to-point communication
• Collective communication
• process topology and management
• one-sided communications
• External interfaces
• Distributed IO
• Process groups, caches, etc.

And that’s just the MPI 3.1 specification. MPI 4.0 adds quite a bit:

Version 4.0: June 9, 2021. This version of the MPI-4 Standard is a major update and
includes significant new functionality. The largest changes are the addition of large-count
versions of many routines to address the limitations of using an int or INTEGER for the
count parameter, persistent collectives, partitioned communications, an alternative way
to initialize MPI, application info assertions, and improvements to the definitions of error
handling. In addition, there are a number of smaller improvements and corrections.

The full standard can be found here (for the latest version) and older specs are here. But what do you guys think? Would proposing the use of MPI-4.0 be a good idea (assuming there are any implementations of it)? I know that this would, most likely, add MPI as a run-time dependency of distributed applications, and might even need you to run it under a supervisor of some kind. But I don’t think that would be a lot to ask people who would use the annex, particularly since they most likely do that anyway. But I thought I would ask here to see what people thought first.

Edit: I know that the spec currently allows you to do whatever you want when implementing the DSA, but having a big Ada implementor company like AdaCore use MPI as the backend for something like the DSA as a modern replacement for the current implementation would probably go a long way to making it easier to use. Ultimately the proposal would be to keep the DSA and, perhaps, extend it with features that MPI has, if necessary to account for advancements in computing.

4 posts - 3 participants

Read full topic