[Mpi-forum] Deadline for next year's release
traff at it.neclab.eu
Thu Sep 3 02:24:53 CDT 2009
isn't the a large part of all these problems the self-imposed deadlines
and self-imposed yearly releases? Is there really consensus that this is
the way to proceed?
As some of you know, I'm not so happy with the state of 2.2 and think we
would have done better by not being so strict about the Helsinki/SC
deadline, and I do not think that we do any good (to the user community,
to ourselves) by continuing this way.
I also agree that waiting for 3 years (until MPI 3.0) for something
like NBC is not at all a good idea.
On Wed, Sep 02, 2009 at 04:35:03PM -0500, Martin Schulz wrote:
> On Sep 2, 2009, at 2:53 PM, Marc-Andre Hermanns wrote:
> >Hi all,
> >maybe just to add to Torsten, who wrapped up the discussion quite
> >- we (here in Helsinki) agreed that it is vital to get some things out
> > to the user soon (like the NBCs) and not have them wait all the way,
> > till MPI 3.0 is settled
> While I see the reasoning for getting something out early, I do agree
> with Bronis: this schedule seems very aggressive and rushed and
> we might not get out of it what we want.
> >- we did not agree, yet, what name such a release would have:
> > 2.3, 2.9, 3.0, ... (that is to be discussed)
> Personally, I think calling anything with 3.* is a mistake: introducing
> just a few new things in 3.0 and then the big additions in a 3.1,
> potentially even things that break applications, will be confusing
> and not consistent to previous MPI versions.
> >I think the main message of Jeff's earlier mail was: If you want to
> >your stuff out soon, you will have to get it to the first reading by
> >march, or you will have to wait till the "big package" is passed in 3
> This seems to mean that proposals will have to get feedback from the
> forum in January or, if you want to allow for at least one round of
> feedback, even in November. This would, in my opinion, rush the
> development of proposals as well as their discussion.
> Also, by cramping this so much together and assuming that most
> proposals that could make this deadline and should be included
> sooner than later make it, the forum will have a large number of big
> proposals to go through at a single meeting.
> >years, as I took it from the discussions that everybody present was
> >reluctant to have another intermediate release.
> What was the reasoning behind that? Why wouldn't the same reason,
> to release important additions early, apply in 2011?
> >Best regards,
> >Torsten Hoefler wrote:
> >>Bronis, all,
> >>>>Note to everyone who is not in the Helsinki meeting: there was
> >>>>consensus that we want some kind of release in November 2010. The
> >>>>exact name of that release is still TBD (likely "3.0", but there's
> >>>>still some discussion about this), but the point is that WG's
> >>>>need to
> >>>>have text ready for 1st readings by the ***MARCH 2010*** Forum
> >>>>in order to be included in the Nov 2010 release.
> >>>>This is not too far away.
> >>>No, it is not. It does not seem realistic to me. We
> >>>would clearly have the nonblocking collectives ready
> >>>but I don't think much else would be. I think we could
> >>>have a LITTLE of the tools stuff ready. From what I
> >>>have seen, I doubt other WGs will get beyond that...
> >>we talked about a staged release, possibly also MPI 2.3. I don't
> >>that we rush anything. I'm positive that the FT group could have a
> >>proposal for consistent error codes and smaller things that are very
> >>important for FT by this time. Other groups like the Hybrid WG could
> >>also have something.
> >>And even if we don't have anything, what can you say against
> >>releasing a
> >>smaller incremental version with just NBCs and minor things.
> >>There was an objection that doing another MPI 2.2-like effort would
> >>a lot of the MPI 3 energy. While I fully agree to this, I'd say that
> >>this seems to be a question of policy. We decide what we discuss
> >>(and we
> >>should have a good clean base now).
> >>I would also like to have NBCs in an MPI release that does *not*
> >>API compatibility. The burden on the user who wants to use NBC
> >>would be
> >>too big (imagine that you had to rewrite your 10^6 SLOC MPI program
> >>run with MPI 3.0 just because you want to use NBCs). A good example
> >>such an API breaker is the necessary MPI_Count discussion.
> >>A staged release would also ensure easy implementation and the timely
> >>availability of the compliant MPI implementations (I suspect that we
> >>will see MPI 2.2 adoption rather soon).
> >>I am really against rush here, we have to evaluate every new
> >>proposal as
> >>rigorously as we evaluated NBCs. If a proposal fails the March
> >>"deadline", then it will simply float into the next release.
> >>All the Best,
> >> Torsten
> >Marc-Andre Hermanns
> >Juelich Supercomputing Centre
> >Institute for Advanced Simulation
> >Forschungszentrum Juelich GmbH
> >D-52425 Juelich
> >Phone : +49-2461-61-2054
> >Fax : +49-2461-61-6656
> >eMail : m.a.hermanns at fz-juelich.de
> >WWW : http://www.fz-juelich.de/jsc/
> >JSC is the coordinator of the
> >John von Neumann Institute for Computing
> >and member of the
> >Gauss Centre for Supercomputing
> >Sitz der Gesellschaft: Juelich
> >Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> >Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
> >Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> > Dr. Ulrich Krafft (stellv. Vorsitzender),
> > Prof. Dr. Harald Bolt,
> > Prof. Dr. Sebastian M. Schmidt
> >mpi-forum mailing list
> >mpi-forum at lists.mpi-forum.org
> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
More information about the mpi-forum