From: Kirk, B. (JSC-EG) <Ben...@na...> - 2008-10-28 22:32:35
|
I agree too. But I vote for Parallel::dont_be_lazy_and_use_this_blocking_recv(); ;-) -Ben ----- Original Message ----- From: Roy Stogner <roy...@ic...> To: lib...@li... <lib...@li...> Sent: Tue Oct 28 12:59:00 2008 Subject: [Libmesh-devel] "recv", "irecv" Just a random thought: would it be better to give these functions human-readable names (receive, nonblocking_receive) instead of MPI-derived names? People familiar with MPI still have to look at our headers to determine that they want Parallel::irecv rather than Parallel::Irecv (as well as to see the function arguments), so I don't know if using the same name truncations buys us anything. --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Kirk, B. (JSC-EG) <Ben...@na...> - 2008-10-29 00:20:56
|
Well, you can always post a nonblocking receive before you are ready to use its contents... There are a couple of places in the code where processor 0 posts a slew of nonblocking receives, and then all processors (including 0) post a blocking send. I guess to be more clear, I have no issue with a nonblocking send paired with a blocking receive or vice versa, but a blocking send paired with a blocking receive is much more likely to be a problem. Do you want to call them all Parallel::send() / Parallel::recv() and use the presence of a request object to discern blocking vs nonblocking, or do you think that would just obfuscate things? -Ben ----- Original Message ----- From: Roy Stogner <roy...@ic...> To: Kirk, Benjamin (JSC-EG) Cc: lib...@li... <lib...@li...> Sent: Tue Oct 28 17:46:40 2008 Subject: Re: [Libmesh-devel] "recv", "irecv" On Tue, 28 Oct 2008, Kirk, Benjamin (JSC-EG) wrote: > I agree too. > But I vote for > > Parallel::dont_be_lazy_and_use_this_blocking_recv(); I can see how blocking sends are nearly always lazy, but receives? I'd think that usually by the time you know you're going to need some data, you don't have any more work you can do until you're finished receiving it. It's the same problem we've got with communication during linear system assembly. --- Roy |
From: Roy S. <roy...@ic...> - 2008-10-29 00:43:18
|
On Tue, 28 Oct 2008, Kirk, Benjamin (JSC-EG) wrote: > Well, you can always post a nonblocking receive before you are ready to > use its contents... There are a couple of places in the code where > processor 0 posts a slew of nonblocking receives, and then all processors > (including 0) post a blocking send. For serialization? I actually think we're going to want to change that behavior in the long run. No idea when we'll get around to changing old code, but eventually I'd like to be able to handle the case where serialized structures wouldn't even fit on a single processor - i.e. even if we want to do I/O from processor 0, we'd do it a chunk at a time. > I guess to be more clear, I have no issue with a nonblocking send > paired with a blocking receive or vice versa, but a blocking send > paired with a blocking receive is much more likely to be a problem. True. > Do you want to call them all Parallel::send() / Parallel::recv() and use > the presence of a request object to discern blocking vs nonblocking, or > do you think that would just obfuscate things? Hmmm... I'm leaning toward "obfuscate things", but it's up to you. --- Roy |
From: Benjamin S. K. <ben...@na...> - 2008-10-29 00:53:24
|
> > > Do you want to call them all Parallel::send() / Parallel::recv() > and use > > the presence of a request object to discern blocking vs > nonblocking, or > > do you think that would just obfuscate things? > > Hmmm... I'm leaning toward "obfuscate things", but it's up to you. Nah... given that Parallel::isend() was my brainchild in the first place I'll defer to you on this. -Ben |
From: Roy S. <roy...@ic...> - 2008-10-28 22:46:45
|
On Tue, 28 Oct 2008, Kirk, Benjamin (JSC-EG) wrote: > I agree too. > But I vote for > > Parallel::dont_be_lazy_and_use_this_blocking_recv(); I can see how blocking sends are nearly always lazy, but receives? I'd think that usually by the time you know you're going to need some data, you don't have any more work you can do until you're finished receiving it. It's the same problem we've got with communication during linear system assembly. --- Roy |