This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
BTW, I totally forgot to mention a notable C++ MPI bindings project
that is the next-generation/successor to OMPI: the Boost C++ MPI
I believe there's also python bindings included...?
On Aug 1, 2007, at 8:30 PM, Jeff Squyres wrote:
> On Jul 31, 2007, at 6:43 PM, Lisandro Dalcin wrote:
>> I am working in the development of MPI for Python, a port of MPI to
>> Python, a high level language with automatic memory management. Said
>> that, in such an environment, having to call XXX.Free() for every
>> object i get from a call like XXX.Get_something() is really an
>> unnecesary pain.
> But I don't see why this means that you need to know if an MPI
> handle points to an intrinsic object or not...?
>> Many things in MPI are LOCAL (datatypes, groups, predefined
>> operations) and in general destroying them for user-space is
>> guaranteed by MPI to not conflict with system(MPI)-space and
>> communication (i.e. if you create a derived datatype four using it in
>> a construction of another derived datatype, you can safely free the
>> Well, for all those LOCAL objects, I could implement automatic
>> deallocation of handles for Python (for Comm, Win, and File, that is
>> not so easy, at freeing them is a collective operation AFAIK, and
>> automaticaly freeing them can lead to deadlocks).
> This is a difficult issue -- deadlocks for removing objects that
> are collective actions. It's one of the reasons the Forum decided
> not to have the C++ bindings automatically free handles when they
> go out of scope.
>> My Python wrappers (mpi4py) are inteded to be used in any platform
>> with any MPI implementation. But things are not so easy, as there are
>> many corner cases in the MPI standard.
> Yes, indeed. :-)
>> Python es a wonderfull, powerfull language, very friendly to write
>> things. Prove of that is the many bug reports I provided here. By
>> using python, I can run all my unittest script in a single MPI run,
>> thus they have the potential to find interaction problems between all
>> parts of MPI. If any of you, OMPI developers, have some knowledge of
>> Python, I invite you to try mpi4py, as you would be able to write
>> fast many many tests, not only for things that should work, but also
>> for things that should fail.
>> Sorry for the long mail. In short, many things in MPI are not clearly
>> designed for languages other than C and Fortran. Even in C++
>> specification, there are things that are unnaceptable, like the
>> open-door to the problem of having dangling references, which
>> could be
>> avoided with negligible cost.
> Yes and no. As the author of the C++ bindings chapter in MPI-2, I
> have a pretty good idea why we didn't do this. :-)
> 1. The reason I cited above: triggering an automatic destructor to
> invoke the corresponding MPI_*_FREE function when local handles go
> out of scope is fraught with deadlock.
> 2. The C++ bindings are just that; they are meant to be building
> blocks to create more interesting C++ class libraries (such as
> OOMPI). They are not intended to be the penultimate C++ interface,
> partly because the value of a good C++ interface is a) an active
> field of research, and b) subjective, and c) potentially dependent
> upon the requirements of the application that it is being designed
> 3. It seemed simplest to use some simple, fundamental C++ concepts
> (namespaces, basic objects) and make the bindings be extremely
> analogous to their C and Fortran counterparts. Otherwise, it would
> be essentially designing a whole new interface with different
> semantics for message passing. This was not deemed appropriate for
> a standard. The standard is meant to be as simple,
> straightforward, and cross-language as possible (and look where it
> is! Imagine if we had tried to make a real class library -- it
> would have led to even more corner cases and imprecision in the
> official standard).
> In short, the Forum *strongly* decided against creating a C++ class
> library for MPI and instead provided building blocks where third
> parties could do whatever they wanted.
>> Anyway, all those issues are minor for
>> me, and the MPI specification is just great. I hope I can find the
>> time to contribute to the MPI-2.1 effort to better define MPI
>> in the corner cases (fortunatelly, there are a really small number of
>> Lisandro Dalcín
>> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
>> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>> Tel/Fax: +54-(0)342-451.1594
>> devel mailing list
> Jeff Squyres
> Cisco Systems