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