[Mpi-forum] another request for iaccept

[George Bosilca]

JeffH,

You might have been misled by the date on the ticket. This is an old (stale
ticket) that was imported from TRAC when we moved to github. Thanks for
pointing it out.

That being said, your point remains valid, we should not force the users to
use complicated solution based on threads doing blocking MPI calls just to
cope with our inability to timely converge toward a reasonable non-blocking
solution.

  George.


On Fri, Feb 26, 2016 at 12:55 AM, Jeff Hammond <jeff.science at gmail.com>
wrote:

>
>
> On Thu, Feb 25, 2016 at 3:40 PM, Balaji, Pavan <balaji at anl.gov> wrote:
>
>>
>> > On Feb 25, 2016, at 2:48 PM, Jeff Squyres (jsquyres) <
>> jsquyres at cisco.com> wrote:
>> >> 1) Low overhead (justifies Isend/Irecv etc.)
>> >> 2) Scarcity of threads (e.g., the BlueGene/L rationale)
>> >
>> > Agreed -- neither of these are likely important for an iconnect/iaccept
>> scenario.
>>
>> I would disagree.  This is *always* a problem since adding threads hurts
>> other operations in the application.  For example, if I need to use a
>> nonblocking iconnect/iaccept in one small part of the application, it now
>> means that every fine-grained PUT/GET/ISEND operation in the rest of the
>> application would be more expensive.
>>
>>
> Does making a blocking operation nonblocking via threads not require
> MPI_THREAD_MULTIPLE, which Open-MPI does not support (
> https://github.com/open-mpi/ompi/issues/157) more than 12 years after its
> standardization?  It seems that a significant fraction of the MPI Forum
> does not believe that thread-safe MPI calls are important, so how can
> anyone argue that threads are a solution to this problem?
>
> Jeff
>
>
>> > But I do think the progression overlap with application threads can be
>> quite useful.
>>
>> Right.  Having a nonblocking operation is not about performance
>> improvements, but that I can now stick in a request into an existing
>> Waitall or Testany in my application.  FWIW, at least one of our
>> applications uses NBC I/O in exactly this way.  Before MPI-3.1, they had to
>> do an event-based model (with Testany) for everything else and a blocking
>> call for I/O, which was inconvenient and hurts performance.
>>
>> >> There are some interactions with multiple-competion routines and
>> limitations in the generalized requests, but fixing generalized requests
>> would be a more general solution.
>> >
>> > Agreed -- fixing generalized requests has been a white whale for quite
>> a while now.
>>
>> There are technical reasons for why this was not easily fixed, unlike
>> iconnect/iaccept where people are bandwidth limited to put together a
>> proposal.
>>
>>   -- Pavan
>>
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>
>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20160226/67c53644/attachment-0001.html>