Cisco Blogs

MPI User Survey: Fun Results

- March 19, 2010 - 0 Comments

Here’s some fun results that we gleaned from the MPI user community survey…

Respondents were asked how much they valued each of the following in MPI on a scale from 1=most important to 5=least important (each item could be rated individually):

  • Runtime performance (e.g., latency, bandwidth, resource consumption, etc.)
  • Feature-rich API
  • Run-time reliability
  • Scalability to large numbers of MPI processes
  • Integration with other middleware, communication protocols, etc.

The first item in the list — runtime performance — may seem silly.  After all, this is high performance computing.  Many on the Forum assumed that everyone would rank runtime performance as the most important thing.  They were wrong (!).

  • Only about half of the respondents rated runtime performance as 1 (“most important”)
  • Another quarter rated runtime performance as 2 (“somewhat important”)
  • The remaining quarter either didn’t answer the question or rated runtime performance as 3 or higher.

Huh.  Fascinating.  I didn’t expect everyone to rate runtime performance as 1, but I guess I expected (much) more than half.  You can speculate on all kinds of meanings here — the data doesn’t specify the reasons why people picked their runtime performance ratings.  My personal guess is that this reflects that MPI is starting to be used in general inter-process communication scenarios; it may be percolating out of pure-HPC scenarios.

Here’s another fun result: respondents were asked to rank the following six proposed MPI-3 topics in order from most important to least important:

  • Nonblocking collectives
  • Revamped one-sided communications (compared to MPI-2.2)
  • MPI application control of fault tolerance
  • New Fortran bindings
  • “Hybrid” programming (MPI in conjunction with threads, OpenMP, etc.)
  • Standardized 3rd party MPI tool support

What’s really interesting is correlating the results of these two questions together.  Two distinct patterns that we noticed:

  1. Those who value nonblocking collectives highly also tend to value runtime performance.
  2. Those who value nonblocking collectives highly also tend to not value a feature-rich MPI API.

Taken together, our interpretation of these two points is that those who value nonblocking collectives see them as a performance enhancement — not yet-another-feature.  Or, put differently:

  • Users will assume that nonblocking communication implementations will perform well
  • Users will assume that nonblocking communication implementations will provide communication / computation overlap

As an MPI implementer, this is good information to know.  Smile

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.