Platform Computing continues in its quest to be a one-stop shop for cluster middleware. Earlier this week the company announced that it had acquired HP-MPI, HP’s Message Passing Interface software. The terms of the deal were not released, but the acquisition involved both intellectual property plus an unspecified number of MPI developers from HP.
For those of you keeping score at home, you probably know that Platform already had an MPI library. A year ago this month, the company bought Scali’s MPI business and rebranded it under the Platform name. With the HP deal, the company will now base its Platform MPI offering on the HP-MPI implementation.
The plan is to integrate the Scali technology into the new Platform MPI, while also maintaining the legacy versions of both the HP and Scali MPI libraries. Scali MPI was known for its superior performance, but it only supported Linux and was never widely used by application software vendors. HP-MPI, on the other hand, supports Linux, Unix and Windows, so can be used in heterogeneous OS environments. It also is already in use by 32 ISVs, including all of the biggies that cover HPC: SIMULIA/Abaqus, ANSYS/Fluent, MSC Software, LSTC, and Accelrys, among others.
According to Tripp Purvis, Platform Computing’s VP of Business Development, HP originally approached Platform about the MPI deal. He says HP was interested in someone that “they could count on to continue to enhance the further develop this product.” Given HP’s commodity approach to the HPC market, that makes sense. Its MPI product was already being used on non-HP gear, so the company had little incentive to keep investing in the software but a definite interest in preserving its viability. From that standpoint, the handoff to a cluster middleware specialist like Platform was the logical thing to do.
That really only leaves Intel MPI and Microsoft’s MPICH2 variant (MS MPI) as alternatives in the commercial realm. Beyond that, there’s still a plethora of publicly-available versions, such as MVAPICH2 and Open MPI. The community probably doesn’t really need so many implementations of a standardized library, so I wouldn’t be surprised to see some more consolidation in the months and years to come.