Re: [OMPI devel] MPI ABI on Linux
Hello Jeff, all, if you allow me my two cents, * Jeff Squyres wrote on Mon, Sep 08, 2008 at 08:44:28PM CEST: > > At the MPI Forum meeting in Dublin, the MPI ABI meeting was... er... > shall we say, "spirited." :-) Both the benefits and drawbacks of an > MPI ABI are widely contended (it's a surprisingly complex topic). it sounds quite daunting. > - If it is ever completed, MPI ABI compliance will be a separate entity > from the MPI 2.x and 3.x standards. ABI compliance will be a checkmark > for an MPI implementation, but will be unrelated to an implementation's > 2.1, 2.2, 3.0, ...etc. compliance. How can that be possible? An MPI ABI will have to be versioned in the same way that the API is versioned. You can have an ABI version for each API version though, I guess. And of course the MPI C++ ABI will require specifying a C++ ABI (which, for Windows, means specifying the compiler and possibly its major release number used), but this is venturing off into details. Cheers, Ralf
Re: [OMPI devel] MPI ABI on Linux
On Sep 9, 2008, at 2:45 AM, Ralf Wildenhues wrote: At the MPI Forum meeting in Dublin, the MPI ABI meeting was... er... shall we say, "spirited." :-) Both the benefits and drawbacks of an MPI ABI are widely contended (it's a surprisingly complex topic). it sounds quite daunting. It is. :-) - If it is ever completed, MPI ABI compliance will be a separate entity from the MPI 2.x and 3.x standards. ABI compliance will be a checkmark for an MPI implementation, but will be unrelated to an implementation's 2.1, 2.2, 3.0, ...etc. compliance. How can that be possible? An MPI ABI will have to be versioned in the same way that the API is versioned. You can have an ABI version for each API version though, I guess. That is correct. My first statement wasn't entirely correct -- "unrelated" is probably not quite the correct word. Each ABI version will be tied to a specific API version. What I was trying to say is that an implementation can be claim to be API compliant, even if it's not ABI compliant. And of course the MPI C++ ABI will require specifying a C++ ABI (which, for Windows, means specifying the compiler and possibly its major release number used), but this is venturing off into details. Not just Windows, right? Ditto for Fortran. -- Jeff Squyres Cisco Systems
Re: [OMPI devel] MPI ABI on Linux
Just for clarification: we had a little internal discussion here about this topic. I fear LANL's interest in this may be somewhat misunderstood. Basically, a few users here have expressed that it would be "convenient" if they could switch MPI implementations without recompiling - that is our complete level of interest in this topic. There are no plans to request this in future procurements, no willingness or interest in devoting LANL resources to accomplishing it. We have much higher priorities than this one. If others in the community have some interest in pursuing it, they are welcome to do so. We are not discouraging anyone from doing so - just making our position on this clear so people can understand why we aren't stepping forward on it. Ralph On Sep 9, 2008, at 6:23 AM, Jeff Squyres wrote: On Sep 9, 2008, at 2:45 AM, Ralf Wildenhues wrote: At the MPI Forum meeting in Dublin, the MPI ABI meeting was... er... shall we say, "spirited." :-) Both the benefits and drawbacks of an MPI ABI are widely contended (it's a surprisingly complex topic). it sounds quite daunting. It is. :-) - If it is ever completed, MPI ABI compliance will be a separate entity from the MPI 2.x and 3.x standards. ABI compliance will be a checkmark for an MPI implementation, but will be unrelated to an implementation's 2.1, 2.2, 3.0, ...etc. compliance. How can that be possible? An MPI ABI will have to be versioned in the same way that the API is versioned. You can have an ABI version for each API version though, I guess. That is correct. My first statement wasn't entirely correct -- "unrelated" is probably not quite the correct word. Each ABI version will be tied to a specific API version. What I was trying to say is that an implementation can be claim to be API compliant, even if it's not ABI compliant. And of course the MPI C++ ABI will require specifying a C++ ABI (which, for Windows, means specifying the compiler and possibly its major release number used), but this is venturing off into details. Not just Windows, right? Ditto for Fortran. -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] MPI ABI on Linux
Thanks Ralph; that helps explain things. I did promise the ABI working group that I would ask the OMPI community to see if anyone wanted to work with Intel on the proof of concept. Let's put a finite end date on the CFP so that I can report back to them: COB this Thursday, Oct 11, 2008. Thanks. On Sep 9, 2008, at 9:03 AM, Ralph Castain wrote: Just for clarification: we had a little internal discussion here about this topic. I fear LANL's interest in this may be somewhat misunderstood. Basically, a few users here have expressed that it would be "convenient" if they could switch MPI implementations without recompiling - that is our complete level of interest in this topic. There are no plans to request this in future procurements, no willingness or interest in devoting LANL resources to accomplishing it. We have much higher priorities than this one. If others in the community have some interest in pursuing it, they are welcome to do so. We are not discouraging anyone from doing so - just making our position on this clear so people can understand why we aren't stepping forward on it. Ralph On Sep 9, 2008, at 6:23 AM, Jeff Squyres wrote: On Sep 9, 2008, at 2:45 AM, Ralf Wildenhues wrote: At the MPI Forum meeting in Dublin, the MPI ABI meeting was... er... shall we say, "spirited." :-) Both the benefits and drawbacks of an MPI ABI are widely contended (it's a surprisingly complex topic). it sounds quite daunting. It is. :-) - If it is ever completed, MPI ABI compliance will be a separate entity from the MPI 2.x and 3.x standards. ABI compliance will be a checkmark for an MPI implementation, but will be unrelated to an implementation's 2.1, 2.2, 3.0, ...etc. compliance. How can that be possible? An MPI ABI will have to be versioned in the same way that the API is versioned. You can have an ABI version for each API version though, I guess. That is correct. My first statement wasn't entirely correct -- "unrelated" is probably not quite the correct word. Each ABI version will be tied to a specific API version. What I was trying to say is that an implementation can be claim to be API compliant, even if it's not ABI compliant. And of course the MPI C++ ABI will require specifying a C++ ABI (which, for Windows, means specifying the compiler and possibly its major release number used), but this is venturing off into details. Not just Windows, right? Ditto for Fortran. -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] MPI ABI on Linux
* Jeff Squyres wrote on Tue, Sep 09, 2008 at 03:07:24PM CEST: >> On Sep 9, 2008, at 6:23 AM, Jeff Squyres wrote: >>> On Sep 9, 2008, at 2:45 AM, Ralf Wildenhues wrote: >>> An MPI ABI will have to be versioned in the same way that the API is versioned. You can have an ABI version for each API version though, I guess. >>> >>> That is correct. My first statement wasn't entirely correct -- >>> "unrelated" is probably not quite the correct word. Each ABI >>> version will be tied to a specific API version. What I was trying >>> to say is that an implementation can be claim to be API compliant, >>> even if it's not ABI compliant. Agreed. And of course the MPI C++ ABI will require specifying a C++ ABI (which, for Windows, means specifying the compiler and possibly its major release number used), but this is venturing off into details. >>> >>> Not just Windows, right? No, but at least on some other systems there is no confusion about which C++ ABI to pick. >>> Ditto for Fortran. Of course. The devil is in the details. > I did promise the ABI working group that I would ask the OMPI community > to see if anyone wanted to work with Intel on the proof of concept. > Let's put a finite end date on the CFP so that I can report back to them: > COB this Thursday, Oct 11, 2008. I'm sure you must mean September not October there. Are things like timeouts, latencies, and small-message sizes intended as part of the ABI as well? IOW, is it expected to be possible to run one process compiled with OpenMPI and one process with MPICH, and have them communicate with each other? Cheers, Ralf, ready be told that I have no idea what I'm talking about ;-)
Re: [OMPI devel] MPI ABI on Linux
On Sep 9, 2008, at 12:14 PM, Ralf Wildenhues wrote: I did promise the ABI working group that I would ask the OMPI community to see if anyone wanted to work with Intel on the proof of concept. Let's put a finite end date on the CFP so that I can report back to them: COB this Thursday, Oct 11, 2008. I'm sure you must mean September not October there. You are absolutely correct -- blah! I meant this week's Thursday, as in: 2 days from now. Are things like timeouts, latencies, and small-message sizes intended as part of the ABI as well? No. The main intent is to be able to compile your MPI app with one MPI and then (on Linux systems, at least) be able to change your LD_LIBRARY_PATH (or similar) and use a different MPI's libmpi.so. IOW, is it expected to be possible to run one process compiled with OpenMPI and one process with MPICH, and have them communicate with each other? Nope; still looking for homogeneous MPI jobs (i.e., all one MPI implementation). -- Jeff Squyres Cisco Systems
