[mpiwg-hybridpm] Call today?

[Jeff Hammond]

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