On 8/1/07, Jeff Squyres wrote:
> BTW, I totally forgot to mention a notable C++ MPI bindings project
> that is the next-generation/successor to OMPI: the Boost C++ MPI
> bindings (boost.mpi).
>
> http://www.generic-programming.org/~dgregor/boost.mpi/doc/
>
> I believe there's also python bind
On 8/6/07, Jeff Squyres wrote:
> On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote:
> > Because many predefined, intrinsic objects cannot (or should not be
> > able to) be freed, acording to the standard.
>
> I understand that. :-) But why would you call XXX.Free() on an
> intrinsic object? If
On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote:
having to call XXX.Free() for every
object i get from a call like XXX.Get_something() is really an
unnecesary pain.
Gotcha.
But I don't see why this means that you need to know if an MPI handle
points to an intrinsic object or not...?
Beca
On 8/1/07, Jeff Squyres wrote:
> On Jul 31, 2007, at 6:43 PM, Lisandro Dalcin wrote:
>> having to call XXX.Free() for every
> > object i get from a call like XXX.Get_something() is really an
> > unnecesary pain.
>
> Gotcha.
>
> But I don't see why this means that you need to know if an MPI handle
BTW, I totally forgot to mention a notable C++ MPI bindings project
that is the next-generation/successor to OMPI: the Boost C++ MPI
bindings (boost.mpi).
http://www.generic-programming.org/~dgregor/boost.mpi/doc/
I believe there's also python bindings included...?
On Aug 1, 2007, at
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_so
On 7/31/07, Jeff Squyres wrote:
> Just curious -- why do you need to know if a handle refers to a
> predefined object?
If I understand correctly, new handles shoud be freed in order to do
not leak things, to follow good programming practices, and being
completelly sure a valgrind run do not repor
On Jul 31, 2007, at 4:52 PM, Lisandro Dalcin wrote:
In general, I think MPI standard should be fixed/clarified in many
places regarding to handling of returned references. Testing for
predefined Comm a Group handling is rather easy, but for Datatypes is
really cumbersome. Perhaps a MPI_Type_is_n
On 7/31/07, Dries Kimpe wrote:
> The MPI_File_get_view description in the standard has some issues related
> to copies and named datatypes:
>
> see
> http://www-unix.mcs.anl.gov/~gropp/projects/parallel/MPI/mpi-errata/discuss/fileview/fileview-1-clean.txt
Indeed, your comment was exactly the sour
* Lisandro Dalcin [2007-07-30 18:19:21]:
> On 7/30/07, George Bosilca wrote:
> > In the data-type section there is an advice to implementors that
> > state that a copy can simply increase the reference count if
> > applicable. So, we might want to apply the same logic here ...
> BTW, you just
On 7/30/07, George Bosilca wrote:
> In the data-type section there is an advice to implementors that
> state that a copy can simply increase the reference count if
> applicable. So, we might want to apply the same logic here ...
BTW, you just mentioned other obscure case. Do this apply to NAMED
d
In the data-type section there is an advice to implementors that
state that a copy can simply increase the reference count if
applicable. So, we might want to apply the same logic here ...
george.
On Jul 30, 2007, at 4:16 PM, Jeff Squyres wrote:
On Jul 30, 2007, at 9:58 AM, Lisandro Dalc
On Jul 30, 2007, at 9:58 AM, Lisandro Dalcin wrote:
In the mean time, I would prefer to follow the standard as close as
possible. If not, some external, stupid test suite (like the one I
have for mip4py) would report that OMPI is wrong about this point.
What exactly are you testing for?
Equal
On 7/29/07, Jeff Squyres wrote:
> On Jul 28, 2007, at 4:41 PM, Lisandro Dalcin wrote:
>
> > In the mean time, I would prefer to follow the standard as close as
> > possible. If not, some external, stupid test suite (like the one I
> > have for mip4py) would report that OMPI is wrong about this poi
On Jul 28, 2007, at 4:41 PM, Lisandro Dalcin wrote:
In the mean time, I would prefer to follow the standard as close as
possible. If not, some external, stupid test suite (like the one I
have for mip4py) would report that OMPI is wrong about this point.
What exactly are you testing for?
BTW,
On 7/28/07, Brian Barrett wrote:
> In my opinion, we conform to the standard. We reference count the
> group, it's incremented on call to MPI_WIN_GROUP, and you can safely
> call MPI_GROUP_FREE on the group returned from MPI_WIN_GROUP. Groups
> are essentially immutable, so there's no way I can
On Jul 28, 2007, at 6:27 AM, Jeff Squyres wrote:
On Jul 27, 2007, at 8:27 PM, Lisandro Dalcin wrote:
MPI_WIN_GET_GROUP returns a duplicate of the group of the
communicator
used to create the window. associated with win. The group is returned
in group.
Well, it seems OMPI (v1.2 svn) is not r
On Jul 27, 2007, at 8:27 PM, Lisandro Dalcin wrote:
MPI_WIN_GET_GROUP returns a duplicate of the group of the communicator
used to create the window. associated with win. The group is returned
in group.
Well, it seems OMPI (v1.2 svn) is not returning a duplicate, comparing
the handles with == C
18 matches
Mail list logo
