[mpiwg-hybridpm] Call today?
Jeff Squyres (jsquyres)
jsquyres at cisco.com
Mon Dec 16 16:44:12 CST 2013
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
> Jeff Hammond
> jeff.science at gmail.com
> mpiwg-hybridpm mailing list
> mpiwg-hybridpm at lists.mpi-forum.org
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
More information about the mpiwg-hybridpm