Re: [Boost-mpi] non blocking collectives
Hi, For those interested, there is a branch called nonblockglob with a first draft and test of ibroadcast. Most of the work involved redesigning the request/handler code. It is not as clean as I'd like yet but you can get the idea. There is a ibroacast_test which seems to be ok... Cheers, Alain ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
Hi, As for the non blocking collective, there is some work in progress in the 'request' branch. I am simplifying the request architecture as most of the non blocking API will be based on it. Basically, I am implementing a system where each type of request is handled by it's specific, dedicated, small handler. Cheer Alain On 21/10/2016 10:11, Lorenz Hübschle-Schneider wrote: Hi, Alain, On 20/10/16 16:15, alainm wrote: There is a branch call globopt with your implementation, if you'd like to have a look at it. testing looks ok. cool! I'm not currently working on any MPI projects, so I can't really test it in-depth, but it seems to work fine with some of my old projects (which have quite a bunch of assertions), too. But I guess that's not surprising given that I used my version of that code before :) I'm looking if there are other places where we could use the same idea. I have a somewhat hacky thing that also forgoes serialization under some circumstances (and thus isn't generally safe) in > https://github.com/lorenzhs/unsafe_mpi but the *_serialize methods should be safe. I implemented them for gatherv and allgatherv, due to the issues with archive sizes you mentioned I skipped (all-)gather without the v. Cheers, Lorenz ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi -- Alain Miniussi Pole Génie Logiciel Scientifique Observatoire de la Côte d'Azur Blv de l'Observatoire, Nice ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
Hi, Alain, On 20/10/16 16:15, alainm wrote: There is a branch call globopt with your implementation, if you'd like to have a look at it. testing looks ok. cool! I'm not currently working on any MPI projects, so I can't really test it in-depth, but it seems to work fine with some of my old projects (which have quite a bunch of assertions), too. But I guess that's not surprising given that I used my version of that code before :) I'm looking if there are other places where we could use the same idea. I have a somewhat hacky thing that also forgoes serialization under some circumstances (and thus isn't generally safe) in > https://github.com/lorenzhs/unsafe_mpi but the *_serialize methods should be safe. I implemented them for gatherv and allgatherv, due to the issues with archive sizes you mentioned I skipped (all-)gather without the v. Cheers, Lorenz ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
I just did gather in the same spirit, the slight difference is that the size of the archive are not homogeneous. So, although it is called gather, it is implemented through MPI_Gatherv. Which raises another issue, it is likely that the same interface could serve the "v" version of the function, thus simplifying the API. We only need to communicate the numbers of array slots along with the size of the archives. Cheers On 20/10/2016 09:17, Lorenz Hübschle-Schneider wrote: Hi everyone, On 19/10/16 10:00, alainm wrote: b) Not so trivial calls need to go though serialization, and manipulate the archive using point to point communication I don't understand why archives would need to be communicated using point-to-point communication. I've posted this before with no response, but under which circumstances would something like https://gist.github.com/lorenzhs/79dab54552fd1f9381da fail? Cheers, Lorenz ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi -- Alain Miniussi Pole Génie Logiciel Scientifique Observatoire de la Côte d'Azur Blv de l'Observatoire, Nice ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
Hi Lorenz, There is a branch call globopt with your implementation, if you'd like to have a look at it. testing looks ok. I'm looking if there are other places where we could use the same idea. Cheers Alain On 20/10/2016 10:40, alainm wrote: Well, since the required buffer will have the same size on every process, this is a very good question indeed. I just trusted the comments on that one. I'll have a closer look shortly (or maybe someone with better knowledge can answer that one) but you're right, we can probably get rid of point to point on that one. The only draw back I can think of is that the communication of the size will act as a barrier. Not sure if this is a real world problem though. Cheers Alain On 20/10/2016 09:17, Lorenz Hübschle-Schneider wrote: Hi everyone, On 19/10/16 10:00, alainm wrote: b) Not so trivial calls need to go though serialization, and manipulate the archive using point to point communication I don't understand why archives would need to be communicated using point-to-point communication. I've posted this before with no response, but under which circumstances would something like https://gist.github.com/lorenzhs/79dab54552fd1f9381da fail? Cheers, Lorenz ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi -- ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi -- Alain Miniussi Pole Génie Logiciel Scientifique Observatoire de la Côte d'Azur Blv de l'Observatoire, Nice ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
Well, since the required buffer will have the same size on every process, this is a very good question indeed. I just trusted the comments on that one. I'll have a closer look shortly (or maybe someone with better knowledge can answer that one) but you're right, we can probably get rid of point to point on that one. The only draw back I can think of is that the communication of the size will act as a barrier. Not sure if this is a real world problem though. Cheers Alain On 20/10/2016 09:17, Lorenz Hübschle-Schneider wrote: Hi everyone, On 19/10/16 10:00, alainm wrote: b) Not so trivial calls need to go though serialization, and manipulate the archive using point to point communication I don't understand why archives would need to be communicated using point-to-point communication. I've posted this before with no response, but under which circumstances would something like https://gist.github.com/lorenzhs/79dab54552fd1f9381da fail? Cheers, Lorenz ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi -- ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
Hi everyone, On 19/10/16 10:00, alainm wrote: b) Not so trivial calls need to go though serialization, and manipulate the archive using point to point communication I don't understand why archives would need to be communicated using point-to-point communication. I've posted this before with no response, but under which circumstances would something like https://gist.github.com/lorenzhs/79dab54552fd1f9381da fail? Cheers, Lorenz ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
Hi, Just a few thoughts. Boost.MPI mapping of MPI could be splitted in two categories, especially for collectives. a) the "trivial" calls (the one with MPI dataypes), on simple type, are directly mapped to it MPI API counter part. b) Not so trivial calls need to go though serialization, and manipulate the archive using point to point communication (sometime, the size need to be communicated first, then the data). Adapting that to non blocking means delegating to MPI_IBcast for a) and to non blocking point to point for b. Now, for case b, the surrent implementation already uses non blocking point to point, but wait for the completion of all requests before returning. I guess the async version will need to offer a kind of request compound object that offer a single API to handle both cases. Regards On 19/10/2016 08:10, MM wrote: On 17 October 2016 at 14:48, alainm wrote: MPI3 is not covered yet. It will probably be done at some points. Regards Alain I'll have a go at implementing ibroadcast based off the broadcast() implementations Thanks ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi -- Alain Miniussi Pole Génie Logiciel Scientifique Observatoire de la Côte d'Azur Blv de l'Observatoire, Nice ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
On 17 October 2016 at 14:48, alainm wrote: > > MPI3 is not covered yet. It will probably be done at some points. > > Regards > > Alain > I'll have a go at implementing ibroadcast based off the broadcast() implementations Thanks ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
Re: [Boost-mpi] non blocking collectives
MPI3 is not covered yet. It will probably be done at some points. Regards Alain On 16/10/2016 23:44, MM wrote: Are there already non blocking collectives or are there any plans to implement them? THanks ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi -- Alain Miniussi Pole Génie Logiciel Scientifique Observatoire de la Côte d'Azur Blv de l'Observatoire, Nice ___ Boost-mpi mailing list Boost-mpi@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-mpi
