[mpich-discuss] Poor performance of Waitany / Waitsome

[Jeff Hammond]

On Wed, Jan 15, 2014 at 2:23 PM, John Grime <jgrime at uchicago.edu> wrote:
> Hi Jeff,
>
>> If Waitall wasn't faster than Waitsome or Waitany, then it wouldn't
>> exist since obviously one can implement the former in terms of the
>> latter
>
>
> I see no reason it wouldn’t exist in such a case, given that it’s an elegant/convenient way to wait for all requests to complete vs. Waitsome / Waitany. It makes sense to me that it would be in the API in any case, much as I appreciate the value of the RISC-y approach you imply.
>
>> it shouldn't be surprising that they aren't as efficient.
>
> I would’t expect them to have identical performance - but nor would I have expected a performance difference of ~50x for the same number of outstanding requests, even given that a naive loop over the request array will be O(N). That loop should be pretty cheap after all, even given that you can’t use cache well due to the potential for background state changes in the request object data or whatever (I’m not sure how it’s actually implemented, which is why I’m asking about this issue on the mailing list).
>
>> The appropriate question to ask is whether Waitany is implemented
>> optimally or not.
>
>
> Well, yes. I kinda hoped that question was heavily implied by my original email!
>
>
>> If you find that emulating Waitany
>> using Testall following by a loop, then that's useful information.
>
> I accidentally the whole thing, Jeff! ;)
>
> But that’s a good idea, thanks - I’ll give it a try and report back!

Testall is the wrong semantic here.  I thought it would test them all
individually but it doesn't.  I implemented it anyways and it is the
worst of all.  I attached your test with my modifications.  Because I
am an evil bastard, I made a ton of whitespace changes in addition to
the nontrivial ones.

Jeff

-- 
Jeff Hammond
jeff.science at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nb_ring.c
Type: text/x-csrc
Size: 5356 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20140115/455fcd0e/attachment.bin>