[mpich-devel] mpi is dying?

[Jeff Hammond]

>> Oh, but then - <bam> - we see on slide 33, "Hide communication inside
>> "distributed array".  OMG it's a high-level abstraction layer on top
>> of MPI that hides the supposed assembly language of parallel
>> programming and makes the programmer productive.
>>
>> But maybe Baidu is exceptional and most HPC programmers who deal with
>> array are doomed to tedious MPI programming.  Let's see if there any
>> distributed array abstraction layers out there that hide MPI.  It took
>> me about 42 microseconds to find http://libelemental.org/ and
>> https://www.emsl.pnl.gov/docs/global/, and those are just the ones
>> that I have a personal relationship with.  And that is just the tip of
>> the MPI library iceberg.
>>
>> So yeah, most people that criticize MPI do so in a manner that is
>> logically equivalent to "Linux is way better than Fortran".
>
>
> This is but one of the points made, but I'm glad you brought it up. Parallel
> HDF5 and Parallel-NetCDF layer on top of MPI-IO routines, as well. so you
> and I know MPI meets one of its goals: be a good foundation for parallel
> libraries.
>
> Can you speak to Dursi's point about Gasnet and Charm++ 's relationship to
> MPI?   It was you, not the GASNET folks, that developed the MPI transport
> layer for ARMCI, after all, but I am not familiar with those groups thought
> processes.

You are the zen master, Rob Latham.  I was having so much fun being
mad, and you managed to ignore all my sarcasm and find something
constructive.  Your talents are clearly wasted on computing; have you
considered a career in peace negotiation? :-)

MPI as a foundation for parallel libraries and thus good software
engineering in general is fundamental to its success.  The IO
libraries you note do far more than MPI can or should while at the
same time subtracting nothing from the usability of MPI.  I am not
aware of equivalent capability in e.g. Chapel or UPC, either in the
standard IO library of the language or in third-party code.  And if it
exists in UPC, I believe that it is constrained by the lack of
layering/scoping capability equivalent to MPI comm, win or file
objects.

To be clear, ARMCI-MPI exists because of Pavan Balaji and Jim Dinan.
When they started that project, I was working on my own non-MPI port
of ARMCI, which I ultimately abandoned upon realizing that the
microseconds I could save with a non-portable implementation were not
worth the lack of portability relative to ARMCI over MPI-2 RMA, which
at that time was standard and supported on Blue Gene, Cray and
InfiniBand systems.  Remodeling and optimizing ARMCI-MPI for MPI-3 was
something that I did due to the obvious practical advantages for
running NWChem and to validate the MPI Forum effort to support Global
Arrays effectively in MPI-3.

GASNet exists in part because of the shortcomings of MPI-2 RMA, which
are described in
http://upc.lbl.gov/publications/bonachea-duell-mpi.pdf.  GASNet
remains relevant because of implementation shortcomings in some MPI
libraries, which still exist but are monotonically decreasing in
magnitude, and because - like MPI - there is a software ecosystem
build around it that users cannot immediately abandon.  My hope is
that GASNet continues to exist, but that the default conduit is one
based upon the latest and greatest RMA and thread-oriented features of
MPI-3 and eventually MPI-4.  But the MPI-3 direct port of UPC should
be faster since, unlike GASNet, MPI-3 exposes a rich set of atomics
that obviate the need for active-messages in many cases.

As for Charm++, Argonne has done some work to show that the unexpected
message performance issue can be mitigated with simple parameter
tuning.  My hope is MPI implementations provide the necessary features
to make Charm++ run as fast as possible relative to lower-level
conduits and that the portability of MPI is recognized of greater
value than maintaining Charm++ backends for MPI, TCP/UDP/IP, IBV,
PAMI, uGNI, etc. etc.  But at extreme scale, the NAMD people probably
need to shave as many microseconds off the comm time as possible,
which may require abandoning MPI.  But such efforts should always be a
means of last resort and, in any case, such events do not support
Dursi's thesis.

Best,

Jeff


-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/