I question the stability claim regarding this new ticket. I was part of the original greq working group with Rob and Darius. Unfortunately few notes remains from our meeting. If I recall correctly we dropped the ball on this proposal for two reasons. 1) The potential use of MPI functions in the greq library. If the greq library uses MPI for its own purposes, it has the potential to expect/require some form of MPI progress (as it will have to call MPI_Test or MPI_Wait) deep inside the greq progress function, function which is called from the MPI progress. This lead to a recursive stack in the MPI progress that was deemed undesirable and potentially error-prone. 2) The major assumption of the proposal, threads being undesirable, seemed to be in contradiction with the hardware evolution (and with the fact that some libraries had async progress). Moreover, the proposal was extremely unclear how the greq progress function interacts with the default progress engine of any MPI library other than MPICH, and about how often the progress functions should be called, especially when testing or waiting for multiple requests. Without such guarantees it is almost impossible to write portable and efficient libraries based on greq. George. On Sat, Nov 22, 2014 at 6:37 PM, Jeff Hammond <[email protected]> wrote:
The greq ticket is quite stable and I'd like to move forward with it without adding baggage.
Let's figure out more details of persistence before linear-combining it with other features.
Jeff
Sent from my iPhone
On Nov 22, 2014, at 4:24 PM, Anthony Skjellum <[email protected]> wrote:
Hi, I think we should put generalized requests in the Persistent group :-) Seriously, I think we need persistent generalized requests. Perhaps we can compare notes offline.
I really don't which group it goes in, but if we are revisiting GREQs we should consider persistent ones.
Tony
Anthony Skjellum, PhD Professor of Computer Science and Software Engineering COLSA Professor of Cybersecurity and Information Assurance Director of the Auburn Cyber Research Center and Lead Cyber Scientist for Auburn Samuel Ginn College of Engineering Auburn University [email protected] or [email protected] cell: +1-205-807-4968 ; office: +1-334-844-6360
CONFIDENTIALITY: This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
________________________________________ From: mpi-forum [[email protected]] on behalf of Jeff Hammond [[email protected]] Sent: Saturday, November 22, 2014 6:02 PM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] which WG for generalized requests?
Martin:
Can you assign one of the two slots for the large-count WG on Monday to be a joint meeting with the greq WG? Again, this assumes Fab will not veto this plan...
One of my main motivations for better greqs is large-count nonblocking collectives, so it makes sense to me to combine the discussion. The other motivation for this at the San Jose meeting is that there's not time for a separate greq WG session since I'm otherwise obligated on Tuesday and it seems imprudent to overlap with WGs that Pavan is driving since he has expressed interest.
Thanks!
Jeff
On Sat, Nov 22, 2014 at 3:44 PM, Jeff Hammond <[email protected]> wrote: Ok. Fab is currently the greq WG lead and I understand he's not going to be absent from the Forum for a while (not immediately).
Martin: Can you assign Pavan and/or me as the WG lead, assuming Fab consents to it?
Thanks,
Jeff
On Sat, Nov 22, 2014 at 3:38 PM, Balaji, Pavan <[email protected]> wrote:
It might make more sense to revive the generalized requests WG. I'm very interested in helping drive the extended generalized requests proposal, whichever WG it ends up being in.
-- Pavan
On Nov 22, 2014, at 5:34 PM, Jeff Hammond <[email protected]> wrote:
I guess there is an inactive WG for generalized requests, but perhaps it makes more sense to discuss in the context of the active p2p or hybrid WG.
Does anyone have any comments on this?
The relevant ticket is https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/457.
My motivation for revisiting this issue is that I've found a number of problems that can be addressed with MPICH-style generalized requests, including large-count nonblocking collectives.
Thanks,
Jeff
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Jeff Hammond [email protected] http://jeffhammond.github.io/
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum