Re: [Boost-mpi] Thread API

Subject: Re: [Boost-mpi] Thread API
From: Alain O Miniussi (alain.miniussi_at_[hidden])
Date: 2012-11-29 07:11:38

On Thu, 2012-11-29 at 12:28 +0100, Matthias Troyer wrote:
> On Nov 28, 2012, at 9:22 PM, Hal Finkel <hfinkel_at_[hidden]> wrote:
> 
> > ----- Original Message -----
> >> From: "Alain O Miniussi" <alain.miniussi_at_oca.eu>
> >> To: "Hal Finkel" <hfinkel_at_[hidden]>
> >> Cc: "Discussion of Boost.MPI development" <boost-mpi_at_[hidden]>
> >> Sent: Wednesday, November 28, 2012 12:14:44 PM
> >> Subject: Re: [Boost-mpi] Thread API
> >> 
> >> 
> >> So, to summarize, we have 3 issues:
> >> 1) syntax: lower vs upper case and mt->threading.
> >> 2) throw an exception if the requested level is not available
> >> 3) macro to control availability of MPI[1|2|3] features
> >> 
> >> 1) ok, I like it better, too :-)
> >> 
> >> 2) exceptions  -> if I understand, it is proposed that we consider
> >> the
> >> unavailability of the requested level as an error and let the flag
> >> 'throw_on_error' decide what to do ?
> >> A few small concerns
> >> * the MPI standard does not seems to consider this an error, so we
> >> do a
> > 
> > The standard does not consider it an error, but it also assumes that the caller will check the provided level. This is a bad assumption, and we must have a better option ;)
> 
> My proposal would be the following:
> 
>   mpi::environment(argc,argv,level); // same semanrics as the C API
>   mpi::environment(argc,argv,mpi::required(level)); // will throws if the level cannot be obtained

See bellow.

> >> semantic change (if I understand correctly 8.7 in MPI3)
> >> * it is not clear that we are allowed to query the available
> >> threading
> >> support level (actually, 8.7 seems to indicated that we can't,
> >> although
> >> there is some weird text associated with the thread_level key of
> >> INFO_ENV). That indicates that the user has no way of probing the
> >> value
> >> before initializing. So if we consider the use case of a user who
> >> wants
> >> to generally throw on error *and* is willing to adapt to the
> >> available
> >> threading level, such a change will make that impossible.
> > 
> > Okay, good point, and calling MPI_Init multiple times may not be safe. How about this: have the constructors take both a 'preferred' and 'required' level; call MPI_Init with the preferred level and throw the exception only if the provided level is below the required level. This has the advantage of being safe and easy, forcing the programming to think about the options, and is not functionally limiting. If a program really has requirements that cannot be expressed as a range in this way, they can always set the required level to the lowest one and fall back to explicit post-construction tests.
> 
> Why not just the post-construction test in this case:
> 
>   mpi::environment env(argc,argv,desired_level);
>   if ( mpi::environment::thread_level() < required_level)
>     throw .....
> 
> I don't think that passing two levels to the constructor is clearer. Do you regularly request a higher level than you require?
> 

I am no sure which one I prefer between the two parameters ctor and the
a-posteriori test. But as far a requesting an higher level than the
minimal required level. I can think of a few situations in a code I am
working on (which is beeing move from pure mpi to hybrid).

Basically, I have a situation (a field that I a moving from real space
to spectral space) where I dynamically select the algorithm base on the
current situation (selection is made through a creational design pattern
to avoid messyness). A vector field is dispatched into 3 1D field, and
in a perfect world I would use threading::multiple, so that is what I
will ask for. But since I cannot expect a widespread support of multiple
(I usually don't have control on the mpi implementation, and multiple
support might comme with its cost) I need to adapt to a lower threading
support.

Granted, if I need to adapt to the worst case scenario (single) anyway,
(usually by assuming that Open MPI is likely to be lying and that it is
at least funneled) that feature is not that useful, but thing might
improve in near future ?

That being said, I do not have a strong opinion between:
a) provide a 2 argument ctor
b) provide one argument ctor, and test provided level afterward.

I just have a preference for b, because I find it simpler (both in terms
of API and explanation, one thing I did not mention is that we could as
weel abort if the requirement is not met in the ctor, since we won't be
able to do any MPI related stuff after that, so going into a lot of
trouble to explain the status of env seems unjustified), and that
throwing in ctor has it's own set of issue (if only being
controversial). 

One thing to consider is that if the requirement is not met, we probably
want to explain what's going on to the user. Which will require some
code. So the test "if (provided < required) { ... }" won't add a lot of
trouble anyway.

Alain

> >> 
> >> Any thought ?
> >> 
> >> 3) Ok, actually the BOOST_MPI_HAS_NOARG_INITIALIZATION would fall in
> >> that category (the feature is mandatory since MPI2 I think).
> >> 
> >> One last question: in my patch, I am still using MPI_Init instead of
> >> the
> >> supposedly equivalent MPI_Init(..single..) (keept for backward
> >> compatibility) I propose to only use MPI_Init_thread in the
> >> implementation.
> > 
> > This is fine with me, so long as we're not keeping compatibility with MPI 1 implementations. Are we?
> 
> 
> We might be - that's why I would propose to guard this with macros and use MPI_Init_thread only if we have at least MPI-2.
> 
> Matthias
> 
> 

-- 
Alain Miniussi
Responsable Tech. Centre de Calcul Haute Performance
Obs. de la Côte d'Azur |Mont Gros: [phone]
BP 4229                |Sophia :   [phone]
06304 Nice Cedex 4     |https://crimson.oca.eu