The original Jovian-2 I/O library was implemented on the SP-2, using IBM's proprietary MPL message passing library. This section describes the issues involved in using MPI instead.
MPI's clear advantage lies in it's portability. Standard MPI code should run without modification under a different implementation. For the most part this is true. A second advantage over MPL is in MPI's definition of communicators, which are basically separate namespaces for messages. This can guarantee that Jovian-2 MPI messages will not be mixed up with application MPI messages. MPI's major disadvantage is that most existing MPI implementations (MPICH, LAM/MPI, CHIMP) are all built atop previously existing layers. As a result the way that you start a parallel MPI program, or even the way it is compiled, can be remarkedly different. This proved to be quite a nuisance when trying to subsititute one implementation of MPI for another, during debugging.
One sticky difference from MPL is how asynchronous sends are handled. In MPL it is perfectly legal to post a non-blocking send, and then never query it to see if it has finished sending. No internal resources are consumed, and it works well to overlap even more communication with computation. MPI (at least the LAM/MPI implementation) requires the user to call an explicit function to mark the message resources for recollection when it has finished sending. This caused excessive memory usage (>100MB) for some benchmarks, and malloc() failures, as the resources were effectively being leaked.