[Mpi3-hybridpm] [EXTERNAL] Re: Endpoints Proposal
Barrett, Brian W
bwbarre at sandia.gov
Wed Mar 20 09:59:31 CDT 2013
On 3/20/13 5:04 AM, "Jeff Hammond" <jhammond at alcf.anl.gov> wrote:
>And Blue Gene/Q has by far the best support for MPI_THREAD_MULTIPLE
>available, so the situation on any other platform is much, much worse.
> What happens if I want to do send/recv from 240 OpenMP threads on
>Intel MIC (let's ignore the PCI connection for discussion purposes)?
>What happens when all the message headers get pushed into a shared
>queue (that certainly can't be friendly to the memory hierarchy) and
>then we enter waitall? If you have good ideas on how to make this as
>efficient as the way it would happen with PAMI-style endpoints, please
>let me know.
Sorry for joining in this thread late, but I apparently am the only one on
the list who sleeps ;).
Guess what, you're not going to get what you want here with the endpoints
proposal on most platforms anyway. There's a space-time tradeoff that's
rapidly moving towards saving space, and it means that almost certainly,
I'm only going to have one network endpoint per address space (since
that's all I need for correctness) and do the dispatching through that
endpoint (either using more match bits, shrinking your tag space or using
a dispatch table based on endpoint id in the header). I'm relatively
agnostic about the current endpoint proposal and think it makes sense from
a programmer comprehension standpoint, but to think that it's going to end
up giving better multithreaded performance than a well optimized
MPI_THREAD_MULTIPLE implementation is, I think, a little ambitious.
Brian W. Barrett
Scalable System Software Group
Sandia National Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 454 bytes
Desc: not available
More information about the mpiwg-hybridpm