- mpiwg-languages - mailman3.cels.anl.gov

Canceled: MPI Languages WG
by Ruefenacht, Martin 17 Feb '22

17 Feb '22

This meeting is during the MPI Forum week. I will cancel since I think we will have enough MPI that week. Thanks, Martin Ruefenacht Topic: MPI Languages WG Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://tum-conf.zoom.us/j/62174408327 Meeting ID: 621 7440 8327 Passcode: 089164 One tap mobile +496938079883,,62174408327#,,,,*089164# Germany +496950502596,,62174408327#,,,,*089164# Germany Dial by your location +49 69 3807 9883 Germany +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 621 7440 8327 Passcode: 089164 Find your local number: https://tum-conf.zoom.us/u/cdiUcscyMs Join by SIP 62174408327(a)fr.zmeu.us Join by H.323 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) Meeting ID: 621 7440 8327 Passcode: 089164

1 0

Canceled: MPI Languages WG
by Ruefenacht, Martin 03 Feb '22

03 Feb '22

Topic: MPI Languages WG Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://tum-conf.zoom.us/j/62174408327 Meeting ID: 621 7440 8327 Passcode: 089164 One tap mobile +496938079883,,62174408327#,,,,*089164# Germany +496950502596,,62174408327#,,,,*089164# Germany Dial by your location +49 69 3807 9883 Germany +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 621 7440 8327 Passcode: 089164 Find your local number: https://tum-conf.zoom.us/u/cdiUcscyMs Join by SIP 62174408327(a)fr.zmeu.us Join by H.323 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) Meeting ID: 621 7440 8327 Passcode: 089164

1 0

Canceled: MPI Languages WG
by Ruefenacht, Martin 13 Dec '21

13 Dec '21

Hello all, I am cancelling the meeting on the 23rd, because I am assuming everyone will be in some form on vacation. So see you in the new year for some fun discussions about ABIs! Martin R Topic: MPI Languages WG Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://tum-conf.zoom.us/j/62174408327 Meeting ID: 621 7440 8327 Passcode: 089164 One tap mobile +496938079883,,62174408327#,,,,*089164# Germany +496950502596,,62174408327#,,,,*089164# Germany Dial by your location +49 69 3807 9883 Germany +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 621 7440 8327 Passcode: 089164 Find your local number: https://tum-conf.zoom.us/u/cdiUcscyMs Join by SIP 62174408327(a)fr.zmeu.us Join by H.323 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) Meeting ID: 621 7440 8327 Passcode: 089164

1 0

Canceled: MPI Languages WG
by Ruefenacht, Martin 02 Dec '21

02 Dec '21

Hello all, I am cancelling the meeting on the 9th since that is the last day of MPI Forum Voting Meeting. I am sure we will all be exhausted of talking about MPI at that point in time… Thanks, Martin R

1 0

Re: [mpiwg-languages] Follow-up: discussion on ref-counted MPI objects
by Lisandro Dalcin 12 Nov '21

12 Nov '21

On Fri, 12 Nov 2021 at 19:26, Joseph Schuchart <schuchart(a)icl.utk.edu> wrote: > Lisandro, All, > > (Lisandro: Apologies if you receive multiple copies, I wasn't sure > whether you're on the list) > > I have some thoughts as a follow-up to the discussion yesterday on > exposing reference-counts of MPI objects to the user. First, let me try > to summarize the use-case: for a developer in a language that supports > ref-counting, it is hard to write ref-counted wrapper objects around MPI > handles *and* be able to pass the handle to third-party libraries > written in languages that do not support whatever ref-counting mechanism > is used (e.g., a wrapper around MPI_Comm in python, passing the handle > to a C library's set_comm() function). Yes, > The idea is that exposing a > reference counting mechanism in MPI to the user would help here because > that is the lowest common denominator shared by all libraries. Is that > correct? (I missed the first couple of minutes, just want to make sure I > get it right) > > but I would add that adding facilities for better handling the lifetime of handles (at least for some types) is not only useful for ref-counted languages like Python, but even for C/C++/Fortran libraries. > The problem now is that passing the handle out of the ref-counted > wrapper to a library potentially creates dangling references because > that library might store the handle and eventually free it without the > wrapper knowing. Bummer. > Or not free it, and then the library caller is responsible for keeping track of the handle and destroying it at a later time. MPI provides no clear recommendation, much less proper APIs, for sane handling of MPI object lifetimes. > > Here is where I am not sure how ref-counting at the MPI library level > would help: how would you know whether the library's set_comm() call > actually increments the ref-count? Right now, you don't. You don't know if the library will ever free the handle, ever. The "contract" has to be written in the library documentation, and there are no general guidelines in the MPI standard. So library developers do whatever they like or think it is the right thing to do (if they ever think about the issue)... and we scientists are terrific software engineers ;-) > Just as you cannot be sure that it > won't destroy the MPI object and leave your handle dangling, you have no > guarantee that the ref-counting would be correct because there is no way > to enforce that across all supported languages. > Indeed. Just adding the APIs is not enough. The standard should add new recommendations. > > As Dan had pointed out, duplicating MPI objects is the right way to go > here. Ask PETSc folks about the messy code they have in place to prevent excessive communicator duplication. They basically had to add their own refcounting for MPI_Comm using attributes, inner comm dupes, etc. So, no, duplication is not always the answer. > It is good practice for libraries to treat handles to MPI objects > as borrowed references and only store handles to duplicates. Alternatively, with my proposal/request, libraries could take ownership of a reference. > Unless > explicitly documented that ownership is transferred, the library should > not destroy the MPI object it received. And then the burden on managing handle lifetime is put on the library caller. > Yes, there is no way to enforce > this in C, so it has to be part of the verbal API contract. But the same > would be true for correct reference counting. I don't see a way around > relying on soft contracts here... > All I'm asking for is the addition of a few APIs [for example, MPI_Type_clone(datatype, &newref) or perhaps MPI_Type_incref(datatype), and so on for other types] that would help to better define SOFT contracts. This is all about soft contracts, there is no way to enforce anything in C. > And as was discussed during the call: MPI libraries may ref-count > internal parts of communicators and datatypes so their duplication > should be fairly lightweight. Except that duplication is not the same as aliasing, and users/libraries may have valid reasons to want to use aliasing. For the case of mpi4py, it is all about being a wrapper as thin as possible. > I realize that there are no duplication > functions for files and windows (I had proposed window duplication at > EuroMPI this year; I'm not what sure the semantics for files would be > though). Would having window and file duplication help here? > How would window duplication work? The Win handle refers to the same memory buffer, then you can attach different attributes on each duplicate? I'm not sure how that behaviour would be useful, although I'm not against it. > > Or did I get any of the discussion wrong? > I think you got it just right. However, I still disagree that duplication is the ultimate solution. I believe this whole subject is already controversial enough. Perhaps we can start with other related things that would be less controversial. For example, relaxing MPI_XXX_Free rules such that the following snippets of code do not error as they currently do: datatype = MPI_INT; MPI_Type_free(&datatype); // freeing built-in datatype = MPI_DATYPE_NULL; MPI_Type_free(&datatype); // freeing NULL and similarly for MPI_Op, MPI_Group, MPI_Info. I'm not sure about Comm, Win, File, but at least freeing the NULL handles should not error. This is just a relaxation of current rules, so it is backward compatible. -- Lisandro Dalcin ============ Senior Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/

1 0

Follow-up: discussion on ref-counted MPI objects
by Joseph Schuchart 12 Nov '21

12 Nov '21

Lisandro, All, (Lisandro: Apologies if you receive multiple copies, I wasn't sure whether you're on the list) I have some thoughts as a follow-up to the discussion yesterday on exposing reference-counts of MPI objects to the user. First, let me try to summarize the use-case: for a developer in a language that supports ref-counting, it is hard to write ref-counted wrapper objects around MPI handles *and* be able to pass the handle to third-party libraries written in languages that do not support whatever ref-counting mechanism is used (e.g., a wrapper around MPI_Comm in python, passing the handle to a C library's set_comm() function). The idea is that exposing a reference counting mechanism in MPI to the user would help here because that is the lowest common denominator shared by all libraries. Is that correct? (I missed the first couple of minutes, just want to make sure I get it right) The problem now is that passing the handle out of the ref-counted wrapper to a library potentially creates dangling references because that library might store the handle and eventually free it without the wrapper knowing. Bummer. Here is where I am not sure how ref-counting at the MPI library level would help: how would you know whether the library's set_comm() call actually increments the ref-count? Just as you cannot be sure that it won't destroy the MPI object and leave your handle dangling, you have no guarantee that the ref-counting would be correct because there is no way to enforce that across all supported languages. As Dan had pointed out, duplicating MPI objects is the right way to go here. It is good practice for libraries to treat handles to MPI objects as borrowed references and only store handles to duplicates. Unless explicitly documented that ownership is transferred, the library should not destroy the MPI object it received. Yes, there is no way to enforce this in C, so it has to be part of the verbal API contract. But the same would be true for correct reference counting. I don't see a way around relying on soft contracts here... And as was discussed during the call: MPI libraries may ref-count internal parts of communicators and datatypes so their duplication should be fairly lightweight. I realize that there are no duplication functions for files and windows (I had proposed window duplication at EuroMPI this year; I'm not what sure the semantics for files would be though). Would having window and file duplication help here? Or did I get any of the discussion wrong? Thanks Joseph

1 0

Canceled: MPI Languages WG
by Ruefenacht, Martin 14 Oct '21

14 Oct '21

Hello all, I have received a couple peoples notices that they won’t be able to make it. And it turns out I can’t either so I will cancel today’s meeting. We shall reconvene in two weeks on the usual schedule. Martin R Topic: MPI Languages WG Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://tum-conf.zoom.us/j/62174408327 Meeting ID: 621 7440 8327 Passcode: 089164 One tap mobile +496938079883,,62174408327#,,,,*089164# Germany +496950502596,,62174408327#,,,,*089164# Germany Dial by your location +49 69 3807 9883 Germany +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 621 7440 8327 Passcode: 089164 Find your local number: https://tum-conf.zoom.us/u/cdiUcscyMs Join by SIP 62174408327(a)fr.zmeu.us Join by H.323 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) Meeting ID: 621 7440 8327 Passcode: 089164

1 0

MPI Languages WG
by Ruefenacht, Martin 16 Sep '21

16 Sep '21

Hello All, I am intending to go forward with the meeting today, but I have just returned from vacation and am still working through emails so I have no agenda. Feel free to attend and bring something up! Below I have forwarded the meeting information, and maybe the event is also being sent? Thanks, Martin From: Martin.Ruefenacht(a)lrz.de When: 15:00 - 16:00 22. July 2021 Subject: MPI Languages WG Location: https://tum-conf.zoom.us/j/62174408327 Topic: MPI Languages WG Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://tum-conf.zoom.us/j/62174408327 Meeting ID: 621 7440 8327 Passcode: 089164 One tap mobile +496938079883,,62174408327#,,,,*089164# Germany +496950502596,,62174408327#,,,,*089164# Germany Dial by your location +49 69 3807 9883 Germany +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 621 7440 8327 Passcode: 089164 Find your local number: https://tum-conf.zoom.us/u/cdiUcscyMs Join by SIP 62174408327(a)fr.zmeu.us Join by H.323 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) Meeting ID: 621 7440 8327 Passcode: 089164

1 0

Canceled: MPI Languages WG
by Ruefenacht, Martin 02 Sep '21

02 Sep '21

Topic: MPI Languages WG Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://tum-conf.zoom.us/j/62174408327 Meeting ID: 621 7440 8327 Passcode: 089164 One tap mobile +496938079883,,62174408327#,,,,*089164# Germany +496950502596,,62174408327#,,,,*089164# Germany Dial by your location +49 69 3807 9883 Germany +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 621 7440 8327 Passcode: 089164 Find your local number: https://tum-conf.zoom.us/u/cdiUcscyMs Join by SIP 62174408327(a)fr.zmeu.us Join by H.323 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) Meeting ID: 621 7440 8327 Passcode: 089164

1 0

Todays Language WG meeting
by Ruefenacht, Martin 02 Sep '21

02 Sep '21

Hello all, I am intending to cancel the meeting if we don’t have anything to discuss. Let me know if you want the meeting to happen! Martin

1 0