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 <[email protected]>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) <[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] _______________________________________________ mpiwg-hybridpm mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm