[mpiwg-hybridpm] Call today?

[Jeff Squyres (jsquyres)]

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/