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).
This is a serious issue in my opinion. I suspect that virtually
every use of MPI_GATHER and the others would fail with the large
interfaces as is, there by making sure no one would be able to use
the large interfaces on a multiuser system.
I agree -- the "large" interface is pretty unusable at this point.
1b. But even worse than that is the fact that, for MPI_GATHER, the
receive buffer is not relevant on non-root processes. So it's valid
for *any* type to be passed for non-root processes (leading to the
exponential interface explosion described above).
I would consider this to be very bad programming practice and not a
good idea to support in the large interface regardless of the cost.
I admit to not knowing what good practices are here; in C, you can
just pass NULL for non-root processes and be done with it. For MPMD
codes in Fortran (e.g., where non-root processes have a different
code path than the root processes), I can imagine passing in any old
buffer that you've got handy since MPI guarantees to ignore it.
One issue is that derived datatypes will never (?) work with the
large interfaces, for that matter I would guess that derived
datatypes probably don't work with medium and possibly small
interfaces. I don't know if there is away around that issue at all
in F90/F95, some places may have to do two installations. I don't
think giving up on all interfaces that conflict with derived types is
a good solution.
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.
So there are multiple options here:
1. Keep chasing a "good" definition of "large" such that most/all
current MPI F90 apps can compile. The problem is that this target
can change over time, and keep requiring maintenance.
2. Stop pursuing "large" because of the problems mentioned above.
This has the potential problem of not providing type safety to F90
MPI apps for the MPI collective interfaces, but at least all apps can
compile, and there's only a small number of 2-choice-buffer functions
that do not get the type safety from F90 (i.e., several MPI
collective functions).
3. Start implementing the proposed F03 MPI interfaces that don't have
the same problems as the F90 MPI interfaces.
I have to admit that I'm leaning more towards #2 (and I wish that
someone who has the time would do #3!) and discarding #1...
I dislike #2 intensely because then I and others couldn't at least
patch the interface scripts before building OpenMPI.
Don't misunderstand me -- by #2, I don't mean ripping the code out of
Open MPI. I simply mean not progressing it any further.
#1 is preferred and just give the users/builders clear notice they
may not cover everything and perhaps a hint as to what directory has
the files to be patched to extend the large interface a bit further.
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. :-\
#3 would be nice but I don't see enough F03 support in enough
compilers at this time. I don't even have a book on the F03 changes
and I program Fortran most of the day virtually every weekday. It
took our group till about 2000 to start using Fortran 90 and almost
everything we do is in Fortran.
Craig -- you probably have better visibility on the state of F03
compilers that me. What's the view from that perspective?
--
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems
