Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

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.

From: Michael Kluskens (mklus_at_[hidden])
Date: 2006-11-06 10:09:13

On Nov 2, 2006, at 7:47 PM, Jeff Squyres wrote:

> On Nov 2, 2006, at 3:18 PM, Michael Kluskens wrote:
>>> So "large" was an attempt to provide *some* of the
>>> interfaces -- but [your] experience has shown that this can do more
>>> harm than good (i.e., make some legal MPI applications uncompilable
>>> because we provide *some* interfaces to MPI_GATHER, but not all).

> Very true; derived data types are always going to be a problem for
> F90/F95 (as I understand those languages). The proposed F03 bindings
> don't have this problem because (again, as I understand the language
> -- and I am *not* a Fortran expert!) they have the equivalent of
> (void*) that we can use for choice buffers.

Not knowing where to look I suspect that derived datatypes will not
be a problem because after more thought I realized that they all must
be just a single Fortran type in the actual code because I can't see
anyway they could be anything but.

> I suppose. I'd be willing to accept a patch for all the things we
> talked about in this thread (e.g., the stuff you did for GATHER
> extrapolated for all the other collectives that need it, and either
> what you did for REDUCE to allow IN_PLACE or expanding IN_PLACE to be
> a unique datatype as we discussed). More specifically, I'd rather
> fix *all* the collectives rather than just GATHER/dimensions and
> REDUCE/IN_PLACE. I unfortunately do not have the cycles to do this
> work myself. :-\

I could write a patch for the other collectives with 2 choice buffers
affected by large -- having looked at it multiple times for GATHER
the way forward is clear to me. Let me know if/when you are ready to
accept a patch, I'd rather not work on it until you are able to merge
it into the trunk so I don't have to redo it if someone else makes
changes to the affected files in the meantime. However, I don't have
time to write test programs to go beyond my testing of GATHER, but
that should not be a problem as I can't see how the other collectives
could be much different in this respect that GATHER.

IN_PLACE would be better handled with a special Fortran datatype but
I'd rather not try to do that until the 2 choice buffers are
finished, to much to handle at one time and I'm not as familiar with
the impact of this change.

Given that the large Fortran 90 interface is only meant to add the 2
choice buffers with the same type, I believe anyone who wants the
large interfaces should be willing to live with the larger interface
file, just like we choose how large of arrays we're going to build
into any of the interfaces.

It would be helpful to know if anyone else is using the Fortran 90
large interfaces in the trunk.