[Mpi3-hybridpm] [EXTERNAL] Re: Endpoints Proposal

[Barrett, Brian W]

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

--
  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20130320/ad1a460d/attachment-0001.bin>