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.
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?
Server Virtualization Business Unit