From jsquyres at [hidden] Fri Sep 12 11:58:49 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Sep 2008 12:58:49 -0400 Subject: [Mpi3-abi] Open MPI and ABI Message-ID: <5E6E7F80-E027-4005-B073-02E8093C90EE@cisco.com> I told the group in Dublin that I would check with the Open MPI community to see who wanted to work on the Linux side of the 6- function ABI proof of concept with our colleagues at Intel MPI. Unfortunately, it seems like no one is interested or has the resources to commit. :-( I got feedback through the LANL Open MPI rep that LANL won't be committing resources to this effort, either, but perhaps Jeff Brown can double check this (I know there are many more groups at LANL than just the team with the Open MPI developer). -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Fri Sep 12 12:17:45 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Sep 2008 13:17:45 -0400 Subject: [Mpi3-abi] ABI: for languages? Message-ID: <8876D2B8-16DF-4937-98BE-F2AC181D57FD@cisco.com> Edric from the Mathworks was kind enough to give me some of his time yesterday; we had a nice chat about the MPI ABI and why the Mathworks wants it. I think I understand his position *much* better now. It was somewhat of an epiphany for me. Let me explain... (Edric: please feel free to correct anything that I say below!) In short, Matlab is a very different kind of product than some of other MPI-based ISV applications out there (reminder: I'm coming from a background of a [limited] survey of ISVs who told me that they *don't* want an MPI ABI -- they only want to run with the MPI's that they specifically choose and QA). With other MPI-based ISV apps, they have a certified application that is QA checked, etc. They have a turnkey solution -- setup your input file, click "go" in the GUI and you get the computed answer. If you have a cluster behind the GUI, you magically get the answer faster. The user doesn't really know/care that MPI is being used behind the scenes. MPI is not a primary focus for the ISV developers -- indeed, they only see it as [yet another] tool to get the job done faster. They do want to use high speed network interconnects, so the multi- protocol MPI implementations do quite well for them. But the point here is that the user doesn't have religion about what MPI is used -- they just want the answer "faster". So the ISV's that I spoke to just QA a single solution stack and then sell that. Matlab, has two key differences from this model: 1. Matlab has an overall philosophy of being able to swap in and out different parts of Matlab to effect the same functionality. For example, you can swap out various computational cores with different implementations to see if they perform better on a particular customer's platform. In the same philosophy, they want to be able to swap out the MPI implementation. Matlab ships with MPICH2 (which they support), but they allow users to swap out to use other (MPICH2-ABI- compatible) MPIs, with the understanding that they are now running in an unsupported (but not discouraged) manner. In short, Matlab ships with lots of plugin modules for all kinds of functionality, but they actively allow and encourage users to swap out those plugins for alternate implementations. MPI, to them, falls under this same philosophy. --> It is worth mentioning that Matlab already dlopen's the MPI .so library and dlsym's to find all the MPI function symbols. The values that they use for constants and sizes for datatypes are simply what are prescribed by MPICH2. They also have templated scripts for setting up the MPI run-time environment and invoking it. So if you don't use MPICH2, the user/administrator can edit these Matlab scripts to setup daemons or whatever is required by that MPI implementation. 2. Matlab has a scripting language that (at the moment) has a few simple API calls that call back to the C MPI API. As such, you can view the Matlab as a high-level scripting language interpreter with MPI bindings. User-level scripts can invoke these API calls and call the back-end MPI implementation. In this way, the Mathworks doesn't care which MPI is on the back-end -- they only want to provide a conduit to whatever MPI implementation is on the back end. In some sense, the run-time characteristics of that MPI implementation are not really their problem -- the user-level Matlab script needs to do whatever it needs to do to be portable between MPI implementations (if it wishes -- similar to other portable MPI libraries/applications, like SCALAPACK, etc.). --- Matlab has some pre-built MPI-based algorithms, but at least for me, point #2 above is the more important one: you can look at Matlab as a [commercial] higher-level scripting language that provides access to the underlying C MPI API. This is a fundamentally different QA issue than other turnkey ISV MPI-based applications. Indeed, the Mathworks largely doesn't care about many of the criticisms of the MPI ABI because they simply aren't relevant to Matlab's desired end goal. So where does this leave us? I now understand the Mathworks' position. But the question is -- how many others are in this position? If there are a lot, then an ABI is a good idea. If there are not -- if the majority are in the "we QA with MPI's X, Y, and Z, and thou shallt not run with any other", then an ABI is not worthwhile. So forgive me, I may be asking a question which has already been answered (my memory is horrid): do we have a concrete list of ISVs, languages, or other software packages that are definitively (and publicly) stating "Yes, I want and will use an MPI ABI in my software"? Can we build this list on the wiki? Perhaps it would also be interesting to build a list of those who do not want an MPI ABI (not counting MPI implementors ;-) ), just for comparison's sake...? ** And I mean a "yes" answer that is stronger than the typical knee- jerk "yes, vendor, give me everything I ask for and more!" reaction. I'm looking for software maintainers who have thought through the issues and understand the tradeoffs and limitations of an MPI ABI. E.g., the Boost C++ MPI bindings guys don't care too much about an MPI ABI because they have C++ compiler ABI issues of their own. In short -- I want to do a cost/benefit analysis. Is it worth our time (and money) to do all this work? Will customers pay for it? Or is there some other perceived gain beyond MPI-based ISV apps being able to conveniently ship a single binary? (that's an honest question, not intended to be provocative) If you're still reading this, thanks for your time. :-) -- Jeff Squyres Cisco Systems From erezh at [hidden] Fri Sep 12 16:00:23 2008 From: erezh at [hidden] (Erez Haba) Date: Fri, 12 Sep 2008 14:00:23 -0700 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <8876D2B8-16DF-4937-98BE-F2AC181D57FD@cisco.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E790CC91072@NA-EXMSG-C105.redmond.corp.microsoft.com> >>>is there some other perceived gain beyond MPI-based ISV apps being able to conveniently ship a single binary? Yes there is. We discussed one example during the MPI conference. There is a great benefit for tools, especially for tools that are using the PMPI interface. Many implementers ship their mpi implementation as a dynamically loaded binary; vendors like Microsoft, Intel HP and others. As such it is more difficult for tools to plugin between the application and the mpi implementation; it is not impossible but still more difficult. Having an API allows MPI implementers, ISV's, tools developers and end user to verify the application with a tool like ISP (University of Utha), without the special need from any of the other parties. Thanks, .Erez -----Original Message----- From: mpi3-abi-bounces_at_[hidden] [mailto:mpi3-abi-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, September 12, 2008 10:18 AM To: MPI 3.0 ABI working group Subject: [Mpi3-abi] ABI: for languages? Edric from the Mathworks was kind enough to give me some of his time yesterday; we had a nice chat about the MPI ABI and why the Mathworks wants it. I think I understand his position *much* better now. It was somewhat of an epiphany for me. Let me explain... (Edric: please feel free to correct anything that I say below!) In short, Matlab is a very different kind of product than some of other MPI-based ISV applications out there (reminder: I'm coming from a background of a [limited] survey of ISVs who told me that they *don't* want an MPI ABI -- they only want to run with the MPI's that they specifically choose and QA). With other MPI-based ISV apps, they have a certified application that is QA checked, etc. They have a turnkey solution -- setup your input file, click "go" in the GUI and you get the computed answer. If you have a cluster behind the GUI, you magically get the answer faster. The user doesn't really know/care that MPI is being used behind the scenes. MPI is not a primary focus for the ISV developers -- indeed, they only see it as [yet another] tool to get the job done faster. They do want to use high speed network interconnects, so the multi- protocol MPI implementations do quite well for them. But the point here is that the user doesn't have religion about what MPI is used -- they just want the answer "faster". So the ISV's that I spoke to just QA a single solution stack and then sell that. Matlab, has two key differences from this model: 1. Matlab has an overall philosophy of being able to swap in and out different parts of Matlab to effect the same functionality. For example, you can swap out various computational cores with different implementations to see if they perform better on a particular customer's platform. In the same philosophy, they want to be able to swap out the MPI implementation. Matlab ships with MPICH2 (which they support), but they allow users to swap out to use other (MPICH2-ABI- compatible) MPIs, with the understanding that they are now running in an unsupported (but not discouraged) manner. In short, Matlab ships with lots of plugin modules for all kinds of functionality, but they actively allow and encourage users to swap out those plugins for alternate implementations. MPI, to them, falls under this same philosophy. --> It is worth mentioning that Matlab already dlopen's the MPI .so library and dlsym's to find all the MPI function symbols. The values that they use for constants and sizes for datatypes are simply what are prescribed by MPICH2. They also have templated scripts for setting up the MPI run-time environment and invoking it. So if you don't use MPICH2, the user/administrator can edit these Matlab scripts to setup daemons or whatever is required by that MPI implementation. 2. Matlab has a scripting language that (at the moment) has a few simple API calls that call back to the C MPI API. As such, you can view the Matlab as a high-level scripting language interpreter with MPI bindings. User-level scripts can invoke these API calls and call the back-end MPI implementation. In this way, the Mathworks doesn't care which MPI is on the back-end -- they only want to provide a conduit to whatever MPI implementation is on the back end. In some sense, the run-time characteristics of that MPI implementation are not really their problem -- the user-level Matlab script needs to do whatever it needs to do to be portable between MPI implementations (if it wishes -- similar to other portable MPI libraries/applications, like SCALAPACK, etc.). --- Matlab has some pre-built MPI-based algorithms, but at least for me, point #2 above is the more important one: you can look at Matlab as a [commercial] higher-level scripting language that provides access to the underlying C MPI API. This is a fundamentally different QA issue than other turnkey ISV MPI-based applications. Indeed, the Mathworks largely doesn't care about many of the criticisms of the MPI ABI because they simply aren't relevant to Matlab's desired end goal. So where does this leave us? I now understand the Mathworks' position. But the question is -- how many others are in this position? If there are a lot, then an ABI is a good idea. If there are not -- if the majority are in the "we QA with MPI's X, Y, and Z, and thou shallt not run with any other", then an ABI is not worthwhile. So forgive me, I may be asking a question which has already been answered (my memory is horrid): do we have a concrete list of ISVs, languages, or other software packages that are definitively (and publicly) stating "Yes, I want and will use an MPI ABI in my software"? Can we build this list on the wiki? Perhaps it would also be interesting to build a list of those who do not want an MPI ABI (not counting MPI implementors ;-) ), just for comparison's sake...? ** And I mean a "yes" answer that is stronger than the typical knee- jerk "yes, vendor, give me everything I ask for and more!" reaction. I'm looking for software maintainers who have thought through the issues and understand the tradeoffs and limitations of an MPI ABI. E.g., the Boost C++ MPI bindings guys don't care too much about an MPI ABI because they have C++ compiler ABI issues of their own. In short -- I want to do a cost/benefit analysis. Is it worth our time (and money) to do all this work? Will customers pay for it? Or is there some other perceived gain beyond MPI-based ISV apps being able to conveniently ship a single binary? (that's an honest question, not intended to be provocative) If you're still reading this, thanks for your time. :-) -- Jeff Squyres Cisco Systems _______________________________________________ mpi3-abi mailing list mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi From lindahl at [hidden] Fri Sep 12 16:37:14 2008 From: lindahl at [hidden] (Greg Lindahl) Date: Fri, 12 Sep 2008 14:37:14 -0700 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <8876D2B8-16DF-4937-98BE-F2AC181D57FD@cisco.com> Message-ID: <20080912213714.GC17643@bx9.net> On Fri, Sep 12, 2008 at 01:17:45PM -0400, Jeff Squyres wrote: > If there are not -- if the majority are in the "we QA with > MPI's X, Y, and Z, and thou shallt not run with any other", then an ABI > is not worthwhile. We knew before we started that many ISVs had this opionion. But if they ever change their minds in the future, the ABI is useful to them. And when they go to test, the ABI saves them a recompile. The early adopters of the ABI will not be ISVs. It will be non-commercial people who want to ship pre-compiled application binaries, and who don't do much testing of individual MPIs or platforms anyway. There are many free non-MPI scientific programs that distribute precompiled binaries. MPI app authors would like to do the same. -- greg From jsquyres at [hidden] Fri Sep 12 16:53:24 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Sep 2008 17:53:24 -0400 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <20080912213714.GC17643@bx9.net> Message-ID: <22696671-B78C-4251-AA29-A82FCB6565C0@cisco.com> Can we build a list of these to see how many packages actually *will* do what you assert? (e.g., as opposed to software maintainers being entranced by the idea of possibly doing it) I would strongly prefer to hear actual software maintainers publicly saying "yes, I will do this" instead of having someone else speak for them. Not to be too untrusting, but there was a stellar example at the Dublin ABI meeting where person A said "trust me; I can speak for group XYZ", but later, group XYZ said exactly the opposite of what person A had previously asserted for them. On Sep 12, 2008, at 5:37 PM, Greg Lindahl wrote: > On Fri, Sep 12, 2008 at 01:17:45PM -0400, Jeff Squyres wrote: > >> If there are not -- if the majority are in the "we QA with >> MPI's X, Y, and Z, and thou shallt not run with any other", then an >> ABI >> is not worthwhile. > > We knew before we started that many ISVs had this opionion. But if > they ever change their minds in the future, the ABI is useful to > them. And when they go to test, the ABI saves them a recompile. > > The early adopters of the ABI will not be ISVs. It will be > non-commercial people who want to ship pre-compiled application > binaries, and who don't do much testing of individual MPIs or > platforms anyway. There are many free non-MPI scientific programs > that distribute precompiled binaries. MPI app authors would like to do > the same. > > -- greg > > _______________________________________________ > mpi3-abi mailing list > mpi3-abi_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Fri Sep 12 16:56:56 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Sep 2008 17:56:56 -0400 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <6B68D01C00C9994A8E150183E62A119E790CC91072@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <7FE180C3-21AD-4458-9E7E-50BD3A54B92B@cisco.com> On Sep 12, 2008, at 5:00 PM, Erez Haba wrote: >>>> is there some other perceived gain beyond MPI-based ISV apps >>>> being able to conveniently ship a single binary? > > Yes there is. > We discussed one example during the MPI conference. There is a great > benefit for tools, especially for tools that are using the PMPI > interface. > Many implementers ship their mpi implementation as a dynamically > loaded binary; vendors like Microsoft, Intel HP and others. As such > it is more difficult for tools to plugin between the application and > the mpi implementation; it is not impossible but still more difficult. I guess it depends on the type of tool, no? The parallel debuggers have gotten along fine without an ABI because they don't hook in at the MPI API layer. Alternate mechanisms exist for them to find out the exact value of MPI_COMM_WORLD (for example). Expansions of this concept are just being introduced into MPI-3.0 for other kinds of tools, too. But if there are oodles of PMPI-based tools that want an ABI, I would encourage them to publicly speak out -- just like anyone who both wants and will actually use an ABI should publicly speak out. > Having an API allows MPI implementers, ISV's, tools developers and > end user to verify the application with a tool like ISP (University > of Utha), without the special need from any of the other parties. I think you mean ABI, right? -- Jeff Squyres Cisco Systems From lindahl at [hidden] Fri Sep 12 16:59:09 2008 From: lindahl at [hidden] (Greg Lindahl) Date: Fri, 12 Sep 2008 14:59:09 -0700 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <22696671-B78C-4251-AA29-A82FCB6565C0@cisco.com> Message-ID: <20080912215909.GA20940@bx9.net> On Fri, Sep 12, 2008 at 05:53:24PM -0400, Jeff Squyres wrote: > Can we build a list of these to see how many packages actually *will* do > what you assert? Sure, you're welcome to ask. But predicting the future is hard, and even package maintainers probably aren't very good at it, i.e. someone who's never considered a binary distribution due to MPI issues may well not leap at the possibility today, but might in a year or two. Instead, you might look at the rapid growth of non-MPI scientific programs being distributed as binaries, and project from there. -- greg From sameer at [hidden] Fri Sep 12 17:01:08 2008 From: sameer at [hidden] (Sameer Shende) Date: Fri, 12 Sep 2008 15:01:08 -0700 (PDT) Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <7FE180C3-21AD-4458-9E7E-50BD3A54B92B@cisco.com> Message-ID: Jeff, > But if there are oodles of PMPI-based tools that want an ABI, I would > encourage them to publicly speak out -- just like anyone who both > wants and will actually use an ABI should publicly speak out. Yes, there are several PMPI-based tools that want an ABI and the compatibility you describe. We, in the TAU project [http://tau.uoregon.edu] will appreciate this very much. Thanks! - Sameer On Fri, 12 Sep 2008, Jeff Squyres wrote: > On Sep 12, 2008, at 5:00 PM, Erez Haba wrote: > > >>>> is there some other perceived gain beyond MPI-based ISV apps > >>>> being able to conveniently ship a single binary? > > > > Yes there is. > > We discussed one example during the MPI conference. There is a great > > benefit for tools, especially for tools that are using the PMPI > > interface. > > Many implementers ship their mpi implementation as a dynamically > > loaded binary; vendors like Microsoft, Intel HP and others. As such > > it is more difficult for tools to plugin between the application and > > the mpi implementation; it is not impossible but still more difficult. > > I guess it depends on the type of tool, no? The parallel debuggers > have gotten along fine without an ABI because they don't hook in at > the MPI API layer. Alternate mechanisms exist for them to find out > the exact value of MPI_COMM_WORLD (for example). Expansions of this > concept are just being introduced into MPI-3.0 for other kinds of > tools, too. > > But if there are oodles of PMPI-based tools that want an ABI, I would > encourage them to publicly speak out -- just like anyone who both > wants and will actually use an ABI should publicly speak out. > > > Having an API allows MPI implementers, ISV's, tools developers and > > end user to verify the application with a tool like ISP (University > > of Utha), without the special need from any of the other parties. > > I think you mean ABI, right? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-abi mailing list > mpi3-abi_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi > From jsquyres at [hidden] Fri Sep 12 17:04:36 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Sep 2008 18:04:36 -0400 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <20080912215909.GA20940@bx9.net> Message-ID: <1F0EBE3B-EDE2-47B9-9752-364402E228C5@cisco.com> On Sep 12, 2008, at 5:59 PM, Greg Lindahl wrote: > Sure, you're welcome to ask. But predicting the future is hard, and > even package maintainers probably aren't very good at it, i.e. someone > who's never considered a binary distribution due to MPI issues may > well not leap at the possibility today, but might in a year or two. > Instead, you might look at the rapid growth of non-MPI scientific > programs being distributed as binaries, and project from there. Can you cite some of these? If MPI is being used as general IPC (vs. traditional HPC environments), that could also be a good motivation. But it would be good to see concrete evidence of this first. -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Fri Sep 12 17:05:27 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Sep 2008 18:05:27 -0400 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: Message-ID: On Sep 12, 2008, at 6:01 PM, Sameer Shende wrote: >> But if there are oodles of PMPI-based tools that want an ABI, I would >> encourage them to publicly speak out -- just like anyone who both >> wants and will actually use an ABI should publicly speak out. > > Yes, there are several PMPI-based tools that want an ABI and the > compatibility you describe. We, in the TAU project > [http://tau.uoregon.edu] will appreciate this very much. Excellent; thanks for the vote. Can you get the other PMPI-based tools to chime in as well? Thanks! -- Jeff Squyres Cisco Systems From lindahl at [hidden] Fri Sep 12 17:27:02 2008 From: lindahl at [hidden] (Greg Lindahl) Date: Fri, 12 Sep 2008 15:27:02 -0700 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <1F0EBE3B-EDE2-47B9-9752-364402E228C5@cisco.com> Message-ID: <20080912222702.GA23952@bx9.net> On Fri, Sep 12, 2008 at 06:04:36PM -0400, Jeff Squyres wrote: > On Sep 12, 2008, at 5:59 PM, Greg Lindahl wrote: > >> Sure, you're welcome to ask. But predicting the future is hard, and >> even package maintainers probably aren't very good at it, i.e. someone >> who's never considered a binary distribution due to MPI issues may >> well not leap at the possibility today, but might in a year or two. >> Instead, you might look at the rapid growth of non-MPI scientific >> programs being distributed as binaries, and project from there. > > Can you cite some of these? http://informatics.umdnj.edu/BioRPMs/ is an example of a group that's doing binary distrbiutions. I think these are all non-MPI. 36 bioinformatics apps 11 molecular modeling apps 29 engineering apps I know that Debian has a ton of scientific apps in it, too, including some MPI apps linked only to their favorite MPI implementation. The reason all this binary distributing is going on is that end-users don't want to compile things, or even rebuild srpms. -- greg From jsquyres at [hidden] Fri Sep 12 18:48:24 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Sep 2008 19:48:24 -0400 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <20080912222702.GA23952@bx9.net> Message-ID: <0A2DC7AB-5E1B-4B48-8468-FEE5D26B6887@cisco.com> On Sep 12, 2008, at 6:27 PM, Greg Lindahl wrote: > http://informatics.umdnj.edu/BioRPMs/ is an example of a group > that's doing > binary distrbiutions. I think these are all non-MPI. > > 36 bioinformatics apps > 11 molecular modeling apps > 29 engineering apps If they're not MPI apps, they don't seem relevant to this discussion, do they? :-) > I know that Debian has a ton of scientific apps in it, too, including > some MPI apps linked only to their favorite MPI implementation. Can you get these maintainers to say that they want / will use an MPI ABI? > The reason all this binary distributing is going on is that end-users > don't want to compile things, or even rebuild srpms. So you're saying: "trust me." :-) Let's hear from the software maintainers, please. -- Jeff Squyres Cisco Systems From lindahl at [hidden] Fri Sep 12 19:19:09 2008 From: lindahl at [hidden] (Greg Lindahl) Date: Fri, 12 Sep 2008 17:19:09 -0700 Subject: [Mpi3-abi] ABI: for languages? In-Reply-To: <0A2DC7AB-5E1B-4B48-8468-FEE5D26B6887@cisco.com> Message-ID: <20080913001909.GC378@bx9.net> On Fri, Sep 12, 2008 at 07:48:24PM -0400, Jeff Squyres wrote: > If they're not MPI apps, they don't seem relevant to this discussion, do > they? :-) I mentioned this a couple of emails ago, but I'll repeat myself: Because few people distributing MPI apps have even considered making a binary distribution due to the lack of an ABI, it might make more sense to look at how many non-MPI scientific apps are distributed as binaries to get an idea of how much demand for an MPI ABI might be in the future. >> I know that Debian has a ton of scientific apps in it, too, including >> some MPI apps linked only to their favorite MPI implementation. > > Can you get these maintainers to say that they want / will use an MPI > ABI? You are welcome to contantact them. I don't know them. >> The reason all this binary distributing is going on is that end-users >> don't want to compile things, or even rebuild srpms. > > So you're saying: "trust me." :-) No, I am not. You are free to directly contact the BioRPMs people and Debian people to find out their motivation. I was just giving you some clues as to where to find them. -- greg From jeffb at [hidden] Mon Sep 15 12:08:53 2008 From: jeffb at [hidden] (Jeff Brown) Date: Mon, 15 Sep 2008 11:08:53 -0600 Subject: [Mpi3-abi] Open MPI and ABI In-Reply-To: <5E6E7F80-E027-4005-B073-02E8093C90EE@cisco.com> Message-ID: <20080915170854.8A6421F8002@ccs-mail.lanl.gov> Jeff, Ralph was not aware of the background of the ABI effort (he is now) when you spoke to him, and that this is a desired capability from the LANL user community. As for committing resources, that's tbd. We may be able to put some effort into the proof of concept morph layer we discussed in Dublin. I suspect Ralph was referring to mods to OpenMPI internals to comply with whatever becomes the ABI spec. Ralph can certainly speak for LANL in that regard. I can imagine that could be a big effort and I understand the sensitivities. As this ABI thing is getting pretty heated, I want to put LANL participation in perspective. When we polled LANL users prior to the start of the forum several user items mapped nicely into the ABI effort. LANL did not initiate this effort but supports it as it addresses several of our user requests, so we joined the working group. The group requested a somewhat impartial third party organization (i.e. not an implementor) to lead the group. We offered to serve as WG lead as a means to get better engaged in the forum and make a contribution. It would be incorrect to say that LANL is "driving" this effort. Our role is more sheparding or facilitating. As you can imagine, LANL is a big place and communication is often less than perfect :>) Jeff At 10:58 AM 9/12/2008, Jeff Squyres wrote: >I told the group in Dublin that I would check with the Open MPI >community to see who wanted to work on the Linux side of the 6- >function ABI proof of concept with our colleagues at Intel MPI. > >Unfortunately, it seems like no one is interested or has the resources >to commit. :-( > >I got feedback through the LANL Open MPI rep that LANL won't be >committing resources to this effort, either, but perhaps Jeff Brown >can double check this (I know there are many more groups at LANL than >just the team with the Open MPI developer). > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi3-abi mailing list >mpi3-abi_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi