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) <[email protected]> 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 <[email protected]> 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) <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm

-- Jeff Hammond [email protected] _______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm

-- Jeff Hammond [email protected]