[mpiwg-hybridpm] Call today?

Jim Dinan james.dinan at gmail.com
Tue Dec 17 07:58:30 CST 2013


Thanks for all of the feedback.  I think Hammond and I should make a pass
on the list and see if we can pare it down to address orthogonality and
composability concerns.  We'll move any info keys that we remove to the
work in progress bin so that we don't lose them.

 ~Jim.


On Mon, Dec 16, 2013 at 5:48 PM, Jeff Hammond <jeff.science at gmail.com>wrote:

> MPI implementations should use JiT compilation to generate an optimal
> message queue for every possible usage.  I am mostly joking, but isn't
> that possibility part of the rationale for the datatypes design?
>
> Jeff
>
> On Mon, Dec 16, 2013 at 4:44 PM, Jeff Squyres (jsquyres)
> <jsquyres at cisco.com> wrote:
> > Just to re-iterate my concern from the info keys ticket discussion
> today...
> >
> > I worry that we're making so many info keys:
> >
> > a) we need to examine and make sure that they're all "mostly" (if not
> entirely) orthogonal from each other -- and then at least look at the
> implications of users asking for multiple of them in a single communicator.
>  Jim (rightfully) pointed out that all the proposed ones are *likely*
> pretty orthogonal already; my point is that we should look through them and
> see if there are any unintended 2nd- or 3rd-level interactions when you
> compose various info key requests.
> >
> > b) I think one possible/likely usage scenario is that a user will say "I
> don't use MPI semantics A-J on this communicator, so I'll ask for these 10
> info keys."  But assuming that the real win for each these info keys is
> actually *removing code* from the progress engine (vs. adding more "if"
> statements that could be costly because of a memory dereference), then an
> MPI implementation may have something like:
> >
> > - a different progress engine for no-any-source
> > - a different progress engine for no-any-tag
> > - a different progress engine for no-any-source+no-any-tag
> > - ...and maybe a few others
> > - the default progress engine
> >
> > So if you ask for N info keys, you actually don't get an optimized
> progress engine because there isn't one supports the particular N info keys
> that the user requested.
> >
> > We all know that at least a bunch of the proposed info keys are
> well-known optimizations that would be great to expose.  My question is
> asking whether this is the right way to expose them -- e.g., should we
> really present some kind of interface that shows which optimizations are
> available in what combinations, so that a user can ask for something that
> will actually result in a nice optimization/speedup/whatever, rather than
> "you asked for N things that I don't have a particular implementation for,
> so you just get the default progress engine."  And it's basically a russian
> roulette game of picking subsets of N info keys -- apps have programatic
> way to know which combination will do something and which will not.
> >
> > My point: is there a better way to do the composition of the various
> optimizations?
> >
> >
> >
> >
> > On Dec 16, 2013, at 12:07 PM, Jeff Hammond <jeff.science at gmail.com>
> wrote:
> >
> >> i will dial in now.  sorry, didn't know it was happening.
> >>
> >> On Mon, Dec 16, 2013 at 11:05 AM, Jeff Squyres (jsquyres)
> >> <jsquyres at cisco.com> wrote:
> >>> Dan and I are on the webex -- is anyone else coming?
> >>>
> >>> If not, we'll happily cede the time to the next meeting (Jan 13,
> 2014).  :-)
> >>>
> >>> --
> >>> Jeff Squyres
> >>> jsquyres at cisco.com
> >>> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> >>>
> >>> _______________________________________________
> >>> mpiwg-hybridpm mailing list
> >>> mpiwg-hybridpm at lists.mpi-forum.org
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
> >>
> >>
> >>
> >> --
> >> Jeff Hammond
> >> jeff.science at gmail.com
> >> _______________________________________________
> >> mpiwg-hybridpm mailing list
> >> mpiwg-hybridpm at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
> >
> >
> > --
> > Jeff Squyres
> > jsquyres at cisco.com
> > For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> > _______________________________________________
> > mpiwg-hybridpm mailing list
> > mpiwg-hybridpm at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> _______________________________________________
> mpiwg-hybridpm mailing list
> mpiwg-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20131217/5f87a078/attachment-0001.html>


More information about the mpiwg-hybridpm mailing list