December 2013 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] ABI
by Jeff Hammond 05 Dec '13

05 Dec '13

Any chance that Intel will issue a patent license for anyone to create a non-commercial, open-source implementation of http://www.google.com/patents/US7966624? Jeff On Thu, Dec 5, 2013 at 4:04 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: > Hi everybody, > > We looked into this matter in substantial detail back in the times of ABI WG (pre-MPI-2.1, I think). Details can be found in https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage#no1 . > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-forum [mailto:[email protected]] On Behalf Of N.M. Maclaren > Sent: Thursday, December 05, 2013 10:44 AM > To: Main MPI Forum mailing list > Subject: Re: [Mpi-forum] ABI > > On Dec 4 2013, Jed Brown wrote: >> >>However, the question of integer (MPICH) versus pointer (OMPI) handles >>is a long-standing impasse. > > Yes, but I don't think that it's the worst issue. > >>Suppose MPICH used intptr_t for handles. I believe pointers are >>treated the same as integers for all the common calling conventions. > > I wouldn't bet on it, especially not in the medium term. It's true on systems like the x86 (and its predecessor in dominance System/370), but I don't know all of the systems that either of those has been ported to. > It certaainly used not to be the case. > >> This >>leaves a question of the predefined constants, which are currently >>compile-time constants of some sort (either integers or addresses of >>privately-defined structs), but I'm not aware of text in the standard >>that requires them to be defined in a header. That is, can we have >> >> extern MPI_Datatype MPI_INT; >> >>in the header and leave it to the library to provide the value? > > The killer there is whether they can be used in initialisations. That would break: > > static MPI_Datatype weeble = MPI_INT; > > Lastly, there are some very nasty differences that would have to be tackled, such as: > > Attributes (especially the I/O ones). I meant to propose some fixes for MPI 3 (the current specification is weird), but didn't do it. Sorry. > But there are probably quite a lot of such corner-cases. > > Implementation assumptions. Not just signals and threading, but the handling of stdin/stdout/stderr, passive one-sided and more. > > This doesn't mean that it can't be done, merely that it isn't as easy as just agreeing the types and values. > > > Regards, > Nick Maclaren. > > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [Mpi-forum] ABI
by Supalov, Alexander 05 Dec '13

05 Dec '13

Hi everybody, We looked into this matter in substantial detail back in the times of ABI WG (pre-MPI-2.1, I think). Details can be found in https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/AbiWikiPage#no1 . Best regards. Alexander -----Original Message----- From: mpi-forum [mailto:[email protected]] On Behalf Of N.M. Maclaren Sent: Thursday, December 05, 2013 10:44 AM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] ABI On Dec 4 2013, Jed Brown wrote: > >However, the question of integer (MPICH) versus pointer (OMPI) handles >is a long-standing impasse. Yes, but I don't think that it's the worst issue. >Suppose MPICH used intptr_t for handles. I believe pointers are >treated the same as integers for all the common calling conventions. I wouldn't bet on it, especially not in the medium term. It's true on systems like the x86 (and its predecessor in dominance System/370), but I don't know all of the systems that either of those has been ported to. It certaainly used not to be the case. > This >leaves a question of the predefined constants, which are currently >compile-time constants of some sort (either integers or addresses of >privately-defined structs), but I'm not aware of text in the standard >that requires them to be defined in a header. That is, can we have > > extern MPI_Datatype MPI_INT; > >in the header and leave it to the library to provide the value? The killer there is whether they can be used in initialisations. That would break: static MPI_Datatype weeble = MPI_INT; Lastly, there are some very nasty differences that would have to be tackled, such as: Attributes (especially the I/O ones). I meant to propose some fixes for MPI 3 (the current specification is weird), but didn't do it. Sorry. But there are probably quite a lot of such corner-cases. Implementation assumptions. Not just signals and threading, but the handling of stdin/stdout/stderr, passive one-sided and more. This doesn't mean that it can't be done, merely that it isn't as easy as just agreeing the types and values. Regards, Nick Maclaren. _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [Mpi-forum] ABI
by N.M. Maclaren 05 Dec '13

05 Dec '13

On Dec 4 2013, Jed Brown wrote: > >However, the question of integer (MPICH) versus pointer (OMPI) handles >is a long-standing impasse. Yes, but I don't think that it's the worst issue. >Suppose MPICH used intptr_t for handles. I believe pointers are treated >the same as integers for all the common calling conventions. I wouldn't bet on it, especially not in the medium term. It's true on systems like the x86 (and its predecessor in dominance System/370), but I don't know all of the systems that either of those has been ported to. It certaainly used not to be the case. > This >leaves a question of the predefined constants, which are currently >compile-time constants of some sort (either integers or addresses of >privately-defined structs), but I'm not aware of text in the standard >that requires them to be defined in a header. That is, can we have > > extern MPI_Datatype MPI_INT; > >in the header and leave it to the library to provide the value? The killer there is whether they can be used in initialisations. That would break: static MPI_Datatype weeble = MPI_INT; Lastly, there are some very nasty differences that would have to be tackled, such as: Attributes (especially the I/O ones). I meant to propose some fixes for MPI 3 (the current specification is weird), but didn't do it. Sorry. But there are probably quite a lot of such corner-cases. Implementation assumptions. Not just signals and threading, but the handling of stdin/stdout/stderr, passive one-sided and more. This doesn't mean that it can't be done, merely that it isn't as easy as just agreeing the types and values. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] ABI
by N.M. Maclaren 05 Dec '13

05 Dec '13

On Dec 5 2013, Pavan Balaji wrote: I agree with you that your posting should be treated as an informative link, and not a proposal for action. >Agreed. I should also add one more item: > > - Bug-fixes (or sorts): if we decide that our MAX_STRING_LENGTH is too > short and want to increase it, that's going to be a pain in the neck with > ABI compatibility. ... That goes to the heart of the matter. If the MPI Forum wanted to assist platforms (i.e. architecture and operating system combinations) to standardise ABIs (and each one would be different), it would need a significant redesign in such areas. It wouldn't be difficult - it would just need a fair amount of effort and be a significant change to the user interface. Personally, I would prioritise a debugging mode, which would be a comparable amount of work (though less change to the interface). But that's by the way .... Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] ABI
by Jed Brown 04 Dec '13

04 Dec '13

Jeff Hammond <jeff.science(a)gmail.com> writes: > 1) Intel has a patent on how to do this with PMPI. You're welcome to > implement that on your own. We've talked about his before. The USPTO is dangerously incompetent and it costs the economy tens of billions per year, news at 11. > 2) Let me know when PETSc and Trilinos are anything-compatible :-P I see you like straw men.

1 0

Re: [Mpi-forum] ABI
by Jed Brown 04 Dec '13

04 Dec '13

Pavan Balaji <balaji(a)mcs.anl.gov> writes: > Agreed. I should also add one more item: > > - Bug-fixes (or sorts): if we decide that our MAX_STRING_LENGTH is > too short and want to increase it, that’s going to be a pain in the > neck with ABI compatibility. Everyone has to change it. If > variables in the status object have interleaved 64-bit and 32-bit > objects, the compiler might pad them and waste space. You can’t > reorder them without breaking ABI. 1. These are also issues within the "MPICH ABI team". 2. I'm not suggesting that the MPI_Forum should standardize an ABI. 3. Having MPICH typedef to intptr_t instead of int, and turning a bunch of integer constants implemented via macros into symbols defined in the library would go most of the way toward making it possible for OMPI to join the "team". 4. The private fields in the MPI_Status object do not need to have the same meaning, just the same size. The MPICH struct currently has a "hole", but if you reordered the last two fields and ditched abi_slush_fund (or OMPI agreed to add one), it would be the same size as the OMPI struct. Is this a real issue? > Even if the eventual goal was for universal ABI compliance, I’d still > recommend starting small with fairly similar MPI implementations, and > then take the lessons learnt to other MPI implementations. In this case, it's more like you're taking the same implementation, forking it several ways, and then asking the forks to converge on their modifications. > And yeah, we are not going to switch to OMPI internal implementation > conventions. These are two different design choices, each of which > has its own advantages. I proposed that you don't have to change those things to have a compatible ABI on architectures that have the same calling convention for pointers and integers of pointer size. This is not universal, but is the case for the common architectures. > Isn’t that the point of having multiple implementations? I would not say that "the point" of multiple implementations is to have different binary *interfaces*. The point is to have different *implementations*. Now if there is a clear technical reason why the binary interfaces cannot be compatible when the implementations are different, there would be nothing to discuss. (This is the case when the source interface throws away all semblance of encapsulation, such as with a C++ template library.)

1 0

Re: [Mpi-forum] ABI
by Jeff Hammond 04 Dec '13

04 Dec '13

1) Intel has a patent on how to do this with PMPI. You're welcome to implement that on your own. 2) Let me know when PETSc and Trilinos are anything-compatible :-P Jeff Sent from my iPhone > On Dec 4, 2013, at 6:23 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> writes: > >> Integer vs. pointer is but one of MANY issues that prevent MPI >> implementations from being ABI compatible. Let's not also forget: > > Yes, there are a lot of issues, but I don't think it's as insurmountable > as it may appear. > >> - Values of constants. Simple integer values are usually easy to >> device/resolve (but don't forget that some integer values are >> specifically chosen on specific platforms). Sentinel values like >> MPI_STATUS_IGNORE are not. > > Section 2.5.4 (Named Constants) has a very short list of items that are > actually required to be compile-time constants. Current implementations > put the values of far more constants into the ABI than the standard > requires. > >> - Size/content of MPI_Status. MPI implementations hide (different) >> non-public fields in MPI_Status. > > These are not so wildly different. Note that the non-public fields can > be used for different things, they just have to add up to the same total > size. > > typedef struct MPI_Status { > int MPI_SOURCE; > int MPI_TAG; > int MPI_ERROR; > MPI_Count count; > int cancelled; > int abi_slush_fund[2]; > } MPI_Status; > > struct ompi_status_public_t { > /* These fields are publicly defined in the MPI specification. > User applications may freely read from these fields. */ > int MPI_SOURCE; > int MPI_TAG; > int MPI_ERROR; > /* The following two fields are internal to the Open MPI > implementation and should not be accessed by MPI applications. > They are subject to change at any time. These are not the > droids you're looking for. */ > int _cancelled; > size_t _ucount; > }; > > >> - Launcher differences. The mpirun/mpiexec (or whatever launcher) is >> inherently different, with different CLI options and configuration, >> between different MPI implementations. > > Doesn't matter because the launcher sets the environment so that the > correct library is used. You would use the MPICH mpiexec to run with > the MPICH libraries and the OMPI mpiexec to run with OMPI libraries. > You only ever interact with your library. > >> - Library names. libmpi.so? libompi.so? libmpich.so? libmpi.a? And so on. > > libmpi.so, obviously. ;-) > > This should only expose the standard symbols. /mpich/lib/libmpi.so and > /ompi/lib/libmpi.so can link to whatever private libraries they want; > those are not part of the ABI. > >> - Dependent libraries. What else do you need to link when linking the >> application? You can (usually) hide this when the MPI is a shared >> library, but a) not always, and b) that doesn't help when MPI is a >> static library. > > A standard ABI is not useful for static libraries because you have to > rebuild (it could save you recompiling all the sources, but you're back > in the build system instead of the runtime). > > Proper shared library etiquette is to always hide dependent libraries. > >> - Compiler ABIs. MPI middleware cannot solve the fact that C++ and >> Fortran compilers cannot (and will not) agree on an ABI (for many good >> reasons, BTW). > > We can't standardize between incompatible compilers, so assume > compatible compilers. > >> - Compiler options. Was the MPI library compiled with -O3? -i8? -32 or -64? ...? > > Same problem we have today. If you compile with the same flags, we'd > like the ABI to match. > >> The fact of the matter is that the MPI API was *specifically designed >> with only source compatibility in mind*. We now have nearly 20 years >> of momentum in different MPI implementations with different >> engineering design choices. >> >> The term "ABI" is a catchall for many, many different issues. People >> seem to think that simply switching libraries at run time is a silver >> bullet -- "if only I could just change my LD_LIBRARY_PATH and use a >> different MPI implementation, then the world would be better". But >> let's also not forget that most users barely know how to use >> LD_LIBRARY_PATH (if at all). > > /mpich/bin/mpiexec -n 2 ./myexecutable > > /ompi/bin/mpiexec -n 2 ./myexecutable > > The launcher sets LD_LIBRARY_PATH. That is feasible (I think) and is > the change that would save distributions, packagers, and users countless > hours. > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] ABI
by Jed Brown 04 Dec '13

04 Dec '13

"Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> writes: > Integer vs. pointer is but one of MANY issues that prevent MPI > implementations from being ABI compatible. Let's not also forget: Yes, there are a lot of issues, but I don't think it's as insurmountable as it may appear. > - Values of constants. Simple integer values are usually easy to > device/resolve (but don't forget that some integer values are > specifically chosen on specific platforms). Sentinel values like > MPI_STATUS_IGNORE are not. Section 2.5.4 (Named Constants) has a very short list of items that are actually required to be compile-time constants. Current implementations put the values of far more constants into the ABI than the standard requires. > - Size/content of MPI_Status. MPI implementations hide (different) > non-public fields in MPI_Status. These are not so wildly different. Note that the non-public fields can be used for different things, they just have to add up to the same total size. typedef struct MPI_Status { int MPI_SOURCE; int MPI_TAG; int MPI_ERROR; MPI_Count count; int cancelled; int abi_slush_fund[2]; } MPI_Status; struct ompi_status_public_t { /* These fields are publicly defined in the MPI specification. User applications may freely read from these fields. */ int MPI_SOURCE; int MPI_TAG; int MPI_ERROR; /* The following two fields are internal to the Open MPI implementation and should not be accessed by MPI applications. They are subject to change at any time. These are not the droids you're looking for. */ int _cancelled; size_t _ucount; }; > - Launcher differences. The mpirun/mpiexec (or whatever launcher) is > inherently different, with different CLI options and configuration, > between different MPI implementations. Doesn't matter because the launcher sets the environment so that the correct library is used. You would use the MPICH mpiexec to run with the MPICH libraries and the OMPI mpiexec to run with OMPI libraries. You only ever interact with your library. > - Library names. libmpi.so? libompi.so? libmpich.so? libmpi.a? And so on. libmpi.so, obviously. ;-) This should only expose the standard symbols. /mpich/lib/libmpi.so and /ompi/lib/libmpi.so can link to whatever private libraries they want; those are not part of the ABI. > - Dependent libraries. What else do you need to link when linking the > application? You can (usually) hide this when the MPI is a shared > library, but a) not always, and b) that doesn't help when MPI is a > static library. A standard ABI is not useful for static libraries because you have to rebuild (it could save you recompiling all the sources, but you're back in the build system instead of the runtime). Proper shared library etiquette is to always hide dependent libraries. > - Compiler ABIs. MPI middleware cannot solve the fact that C++ and > Fortran compilers cannot (and will not) agree on an ABI (for many good > reasons, BTW). We can't standardize between incompatible compilers, so assume compatible compilers. > - Compiler options. Was the MPI library compiled with -O3? -i8? -32 or -64? ...? Same problem we have today. If you compile with the same flags, we'd like the ABI to match. > The fact of the matter is that the MPI API was *specifically designed > with only source compatibility in mind*. We now have nearly 20 years > of momentum in different MPI implementations with different > engineering design choices. > > The term "ABI" is a catchall for many, many different issues. People > seem to think that simply switching libraries at run time is a silver > bullet -- "if only I could just change my LD_LIBRARY_PATH and use a > different MPI implementation, then the world would be better". But > let's also not forget that most users barely know how to use > LD_LIBRARY_PATH (if at all). /mpich/bin/mpiexec -n 2 ./myexecutable /ompi/bin/mpiexec -n 2 ./myexecutable The launcher sets LD_LIBRARY_PATH. That is feasible (I think) and is the change that would save distributions, packagers, and users countless hours.

1 0

Re: [Mpi-forum] ABI
by Pavan Balaji 04 Dec '13

04 Dec '13

Agreed. I should also add one more item: - Bug-fixes (or sorts): if we decide that our MAX_STRING_LENGTH is too short and want to increase it, that’s going to be a pain in the neck with ABI compatibility. Everyone has to change it. If variables in the status object have interleaved 64-bit and 32-bit objects, the compiler might pad them and waste space. You can’t reorder them without breaking ABI. Even if the eventual goal was for universal ABI compliance, I’d still recommend starting small with fairly similar MPI implementations, and then take the lessons learnt to other MPI implementations. And yeah, we are not going to switch to OMPI internal implementation conventions. These are two different design choices, each of which has its own advantages. Isn’t that the point of having multiple implementations? But more importantly, from a practicality standpoint, that’s a huge code churn which I can’t imagine either code base will be willing to go through. — Pavan On Dec 4, 2013, at 6:01 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Dec 4, 2013, at 4:23 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> It would make a _huge_ difference for distributions if MPICH and Open >> MPI could have a compatible ABI. > > We, too, would be happy if MPICH adopted all of Open MPI's internal implementation conventions. > > ...but I don't see that happening any time soon. > > I don't say this glibly; there are years of momentum and complicated engineering issues involved. More below. > >> However, the question of integer (MPICH) versus pointer (OMPI) handles >> is a long-standing impasse. > > To be blunt: this totally misses the point. > > Integer vs. pointer is but one of MANY issues that prevent MPI implementations from being ABI compatible. Let's not also forget: > > - Values of constants. Simple integer values are usually easy to device/resolve (but don't forget that some integer values are specifically chosen on specific platforms). Sentinel values like MPI_STATUS_IGNORE are not. > - Size/content of MPI_Status. MPI implementations hide (different) non-public fields in MPI_Status. > - Launcher differences. The mpirun/mpiexec (or whatever launcher) is inherently different, with different CLI options and configuration, between different MPI implementations. > - Run-time system differences. Some MPI's support different run-time systems, some don't. This is typically exposed through the launcher, but also has impact on the MPI processes themselves. More specifically: the launcher and the MPI library (and support libraries) usually go in pairs and cannot be separated. > ==> Note that this is a giant problem. Many have tried to have create a unified parallel run-time over the past ~15 years. I think it's fair to say that none have succeeded (i.e., none have taken over the world / become the one run-time system that everyone uses). > - Library names. libmpi.so? libompi.so? libmpich.so? libmpi.a? And so on. > - Dependent libraries. What else do you need to link when linking the application? You can (usually) hide this when the MPI is a shared library, but a) not always, and b) that doesn't help when MPI is a static library. > - Compiler ABIs. MPI middleware cannot solve the fact that C++ and Fortran compilers cannot (and will not) agree on an ABI (for many good reasons, BTW). > - Compiler options. Was the MPI library compiled with -O3? -i8? -32 or -64? ...? > > The fact of the matter is that the MPI API was *specifically designed with only source compatibility in mind*. We now have nearly 20 years of momentum in different MPI implementations with different engineering design choices. > > The term "ABI" is a catchall for many, many different issues. People seem to think that simply switching libraries at run time is a silver bullet -- "if only I could just change my LD_LIBRARY_PATH and use a different MPI implementation, then the world would be better". But let's also not forget that most users barely know how to use LD_LIBRARY_PATH (if at all). > > Sure, ABI between different releases of the same (MPI implementation+compiler+environment) is a Good Thing -- users want that. And I think all major MPI implementations deliver that today. It sure makes upgrading the MPI implementation a lot easier on the user. > > But ABI between different implementations is quite a different animal, with an entirely different set of challenges and payoffs. > > (I'm sure this post will inspire some impassioned replies :-) ) > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] ABI
by Jeff Squyres (jsquyres) 04 Dec '13

04 Dec '13

On Dec 4, 2013, at 4:23 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > It would make a _huge_ difference for distributions if MPICH and Open > MPI could have a compatible ABI. We, too, would be happy if MPICH adopted all of Open MPI's internal implementation conventions. ...but I don't see that happening any time soon. I don't say this glibly; there are years of momentum and complicated engineering issues involved. More below. > However, the question of integer (MPICH) versus pointer (OMPI) handles > is a long-standing impasse. To be blunt: this totally misses the point. Integer vs. pointer is but one of MANY issues that prevent MPI implementations from being ABI compatible. Let's not also forget: - Values of constants. Simple integer values are usually easy to device/resolve (but don't forget that some integer values are specifically chosen on specific platforms). Sentinel values like MPI_STATUS_IGNORE are not. - Size/content of MPI_Status. MPI implementations hide (different) non-public fields in MPI_Status. - Launcher differences. The mpirun/mpiexec (or whatever launcher) is inherently different, with different CLI options and configuration, between different MPI implementations. - Run-time system differences. Some MPI's support different run-time systems, some don't. This is typically exposed through the launcher, but also has impact on the MPI processes themselves. More specifically: the launcher and the MPI library (and support libraries) usually go in pairs and cannot be separated. ==> Note that this is a giant problem. Many have tried to have create a unified parallel run-time over the past ~15 years. I think it's fair to say that none have succeeded (i.e., none have taken over the world / become the one run-time system that everyone uses). - Library names. libmpi.so? libompi.so? libmpich.so? libmpi.a? And so on. - Dependent libraries. What else do you need to link when linking the application? You can (usually) hide this when the MPI is a shared library, but a) not always, and b) that doesn't help when MPI is a static library. - Compiler ABIs. MPI middleware cannot solve the fact that C++ and Fortran compilers cannot (and will not) agree on an ABI (for many good reasons, BTW). - Compiler options. Was the MPI library compiled with -O3? -i8? -32 or -64? ...? The fact of the matter is that the MPI API was *specifically designed with only source compatibility in mind*. We now have nearly 20 years of momentum in different MPI implementations with different engineering design choices. The term "ABI" is a catchall for many, many different issues. People seem to think that simply switching libraries at run time is a silver bullet -- "if only I could just change my LD_LIBRARY_PATH and use a different MPI implementation, then the world would be better". But let's also not forget that most users barely know how to use LD_LIBRARY_PATH (if at all). Sure, ABI between different releases of the same (MPI implementation+compiler+environment) is a Good Thing -- users want that. And I think all major MPI implementations deliver that today. It sure makes upgrading the MPI implementation a lot easier on the user. But ABI between different implementations is quite a different animal, with an entirely different set of challenges and payoffs. (I'm sure this post will inspire some impassioned replies :-) ) -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0