premature to speak of the success of MPI

Al Geist (geist@msr.epm.ornl.gov)
Fri, 10 Jan 1997 22:48:21 -0500 (EST)

>Ian wrote:
>[Aside: Not so long
>ago it would still have been premature to speak of the success of MPI, but I
>think we can all agree that it's now safe to do so - I was amused to notice
>recently that last year's "EuroPVM 1996" meeting will this year be called
>"EuroPVM-MPI'97" :-]

Actually this was too amusing to let pass. (-:
The facts are that EuroPVM 1996 was the largest PVM user's group meeting
to date. And while the use of PVM continues to grow at a rate
far larger than MPI, it is also true that there is a growing
body of MPI users who would benefit from a meeting like EuroPVM
so next year it is being called EuroPVM-MPI'97.

And to add my two cents in to the Dave and MPI-is-too-complex story.
YES, MPI is too complex. Not only is it a great deal of work
for the vendors and implementors who must support and maintain
their versions, but also for the users who are presented with
many ways of moving data in their application.
Why so many ways? Well one argument Ian gave is so every vendor
will have a "fast" way to move data. And I agree.
Unfortunately the price we paid in MPI for "Performance at all costs"
is a very large API.

The very richness of MPI may hurt us in the long run
by decreasing its portability in the following way:
Scenario: I am an application developer.
My site has two different computers Machine1 and Machine2
I discover that the fastest way to move data on Machine1
is MPI routines x, y
My tests show that the fastest way to move data on Machine2
is MPI routines a, b
So to make sure my application always get peak performance
I develop it to use both methods with a compile or runtime switch
to choose between them.

Flashback: Before I started designing MPI-1 with the forum
(with a goal of developing a portable message-passing interface)
my application looked very similar except instead of using
MPI routines x, y and MPI routines a, b
it used Vendor1 routines x,y and Vendor2 routines a,b
What have I gained by using MPI? Well maybe if these vendors
go out of business my application will still run. That's a plus.
But I may find I need to change routines once again to
use the fastest MPI routines the remaining vendors supply. deja vu.

Dave is arguing that we, the forum, should consider simplifying
the MPI API. Realisticly, I do not believe we can do this.
We are just too far down the design path.
We designed MPI block by block following a particular set of goals.
A key goal was making sure all vendors could produce high performance
implementations. I think we have done a reasonable job within our constraints.

Al Geist