Mark Hahn wrote:
If there is an ABI then we have a fighting chance at focusing on the
applications and not the ever-so-slightly-strange version of whichever
flavor of MPI that they chose to use.
wonderful! yes: ABI standards are good and proprietary
implementations (which inherently provide
> If there is an ABI then we have a fighting chance at focusing on the
> applications and not the ever-so-slightly-strange version of whichever
> flavor of MPI that they chose to use.
wonderful! yes: ABI standards are good and proprietary
implementations (which inherently provide only negative
Jeff Squyres wrote:
I have a followup question:
Who, exactly, wants an MPI ABI? I have seen a vocal few voice their
opinions (both for and against). But these are not representative of
Me... please, please really... I don't want 7 MPI implementations on
my customers clusters anymo
On Sun, Apr 03, 2005 at 02:19:39PM -0400, Jeff Squyres wrote:
> If so, are we therefore in agreement that a MorphMPI-like approach is a
> good first step?
No, because we apparently disagree about what MorphMPI is. You claim
it's a lot less work than an ABI; I claim it's about the same. We
both a
On Mar 26, 2005, at 7:50 PM, Greg Lindahl wrote:
I guess I don't understand your reluctance to accept a MorphMPI-like
solution:
You have repeated your original MorphMPI attributes. I responded to
them, and I don't see any sign that you've read my response. This is
not the way discussions are u
Greg Lindahl wrote:
On Sat, Mar 26, 2005 at 06:47:41AM -0500, Jeff Squyres wrote:
I guess I don't understand your reluctance to accept a MorphMPI-like
solution:
You have repeated your original MorphMPI attributes. I responded to
them, and I don't see any sign that you've read my response. This
On Sat, Mar 26, 2005 at 06:47:41AM -0500, Jeff Squyres wrote:
> Regardless of which way you choose, your statement "No internals have
> to change" is inaccurate. At a minimum, *EVERY* MPI API function in
> somebody's implementation will have to change.
That's what I call the interface, yes. I
On Mar 25, 2005, at 6:26 PM, Greg Lindahl wrote:
Making even 2 MPI implementations agree on an ABI is an enormous
amount
of work. Given that two major MPI implementations take opposite sides
on the pointers-vs.integers for MPI handles debate (and I suspect that
neither is willing to change), j
MPBI
Patrick Geoffray wrote:
Jeff Squyres wrote:
MorphMPI (or, as Patrick suggests, we need a cooler name -- PatrickMPI?
PMPI is already taken...
I am very bad with names. UMPI for Universal MPI ?
Patrick
Greg Lindahl wrote:
You yourself said how MPI implementers would actually implement this
without needing to change any internals: Make the C interface routines
do the same thing that F77 does today. Elapsed time: a few months,
same as MorphMPI. No internals need to be changed.
Now I get it, I t
Greg Lindahl wrote:
On Fri, Mar 25, 2005 at 06:03:15PM -0500, Patrick Geoffray wrote:
What Jeff thought is a nightmare, I believe, is to have to decide a
common interface and then force the MPI implementations to adopt this
interface internally instead of having them translating on the fly.
Jeff Squyres wrote:
MorphMPI (or, as Patrick suggests, we need a cooler name -- PatrickMPI?
PMPI is already taken...
I am very bad with names. UMPI for Universal MPI ?
Patrick
--
Patrick Geoffray
Myricom, Inc.
http://www.myri.com
On Fri, Mar 25, 2005 at 05:49:13PM -0500, Jeff Squyres wrote:
> MorphMPI (or, as Patrick suggests, we need a cooler name -- PatrickMPI?
> ;-) ) is the work of 1 grad clever student (or anyone else industrious
> enough). Elapsed time: a few months.
Right.
> Making even 2 MPI implementations ag
On Fri, Mar 25, 2005 at 06:03:15PM -0500, Patrick Geoffray wrote:
> What Jeff thought is a nightmare, I believe, is to have to decide a
> common interface and then force the MPI implementations to adopt this
> interface internally instead of having them translating on the fly.
Ah. But no one ev
Greg Lindahl wrote:
Patrick, if you read what both Jeff and I wrote, I believe it's clear
we both understand that part, because we've both mentioned that
particular implementation solution. What I was trying to understand
was why Jeff thought this was a huge nightmare.
What Jeff thought is a ni
On Mar 25, 2005, at 5:03 PM, Greg Lindahl wrote:
I don't see it that way. First, the implementations of the translation
layers will be done by each MPI implementations.
In which case it's basically the same as doing an ABI. Or did I miss
something? Does this somehow save a significant amount
On Fri, Mar 25, 2005 at 02:59:18PM -0500, Patrick Geoffray wrote:
> I don't see it that way. First, the implementations of the translation
> layers will be done by each MPI implementations.
In which case it's basically the same as doing an ABI. Or did I miss
something? Does this somehow save a
Hi Greg,
Greg Lindahl wrote:
I think this overall idea falls short of the benefit of an ABI for a
couple of reasons. The first is that it's unlikely to get wide
distribution if it doesn't come with MPI implementations. The second
is that it's harder to maintain "out of tree"; the minute that an
Hi Jeff,
Jeff Squyres wrote:
You get the idea.
This is pretty much the position I reached after talking with other MPI
developers and some ISVs. Bill's paper shows that it is technically
possible, what is missing is the critical mass. We may have that today.
There's a slight performance pe
On Mar 24, 2005, at 8:34 PM, Greg Lindahl wrote:
A similar idea was actually written up by Bill Gropp and was mentioned
by him 5 weeks ago on the beowulf list. Quoth he:
| I wrote a paper that appeared in the EuroPVMMPI'02 meeting that
discusses
| the issues of a common ABI. The paper is "Bui
> Create a new software project (preferably open source, preferably with
> an BSD-like license so that ISV's can incorporate this software into
> their products) that provides a compatibility layer for all the
> different MPI implementations out there. Let's call it MorphMPI.
Jeff,
A similar
21 matches
Mail list logo
