Is It Time to Look Beyond MPI?
MPI…the acronym stands for Message Passing Interface, yet in some places is nearly synonymous with HPC. While this was true in years past, is it still the case? A recent blog by PhD candidate Andreas Schäfer (specialty: HPC, supercomputing, and discrete optimization) tackles this subject, raising a number of excellent questions in the process.
“MPI is in the peculiar situation of being one of the most widely used technologies in HPC and supercomputing, despite being declared dead since decades,” he writes. “Lately however, my nose is picking up some smells which are troubling me. And others.”
Schäfer says he’s not jumping on the MPI is dead bandwagon. If anything, this technology has shown an amazing tenacity, continuing through multiple HPC advances. InfiniBand, multicore, accelerators have all challenged MPI to one degree or another, and MPI doesn’t die, it adapts – all the way to the next big frontier: evolving MPI for exascale computing.
Here are some of the main points that Schäfer touches on:
- Why so many MPI implementations are struggling to support MPI_THREAD_MULTIPLE well.
- Issues with sending/receiving more than 2 GB en block.
- C++ Bindings Removed from MPI-3, although Boost.MPI brings back many of the “missing” features.
- How to achieve asynchronous progress and the problems with each approach, and a short discussion on community expectations. Schäfer wonders about the possibility of expressing parallelism “in a generic, user-friendly way.”
- Issues with broken, unmaintained code and missing features.
In summary of his points, Schäfer writes:
1. MPI is not becoming easier to use, but harder. The voodoo dance an ordinary user has to complete to max out e.g. perfectly ordinary two-socket, 16-core nodes is inane:
polling MPI for asynchronous progress,
using a custom locking regime to funnel MPI calls into one thread,
pack data into arbitrary chunks to skirt the limitations of 32-bit ints.
2. Previously usable and useful features are being removed, sometimes confusing, sometimes even alienating users.
3. Trivial changes (e.g. the use of size_t) seem next to impossible to implement.
Schäfer says that while he doesn’t see MPI going away anytime soon, there are trends toward generic computational libraries and domain-specific problem solving environments. He also points to HPX (High Performance ParallelX) as a possible path forward. While not as mature, it uses C++ instead of C, which has according to Schäfer, “some elegant ways of managing complexity.”