I got it. You're right, it might not related to MPI. I need to figure out what's the possible reason for it. Again, thanks for your help.
Linbao On Thu, Oct 21, 2010 at 12:06 PM, Eugene Loh <eugene....@oracle.com> wrote: > My main point was that, while what Jeff said about the short-comings of > calling timers after Barriers was true, I wanted to come in defense of this > timing strategy. Otherwise, I was just agreeing with him that it seems > implausible that commenting out B should influence the timing of A, but I'm > equally clueless what that real issue is. I have seen cases where the > presence or absence of code that isn't executed can influence timings > (perhaps because code will come out of the instruction cache differently), > but all that is speculation. It's all a guess that what you're really > seeing isn't really MPI related at all. > > Storm Zhang wrote: > > Hi, Eugene, You said: > " The bottom line here is that from a causal point of view it would seem > that B should not impact the timings. Presumably, some other variable is > actually responsible here." Could you explain it in more details for the > second sentence. Thanks a lot. > > On Thu, Oct 21, 2010 at 9:58 AM, Eugene Loh <eugene....@oracle.com> wrote: > > >> Jeff Squyres wrote: >> >> MPI::COMM_WORLD.Barrier(); >>> if(rank == master) t1 = clock(); >>> "code A"; >>> MPI::COMM_WORLD.Barrier(); >>> if(rank == master) t2 = clock(); >>> "code B"; >>> >>> Remember that the time that individual processes exit barrier is not >>> guaranteed to be uniform (indeed, it most likely *won't* be the same). MPI >>> only guarantees that a process will not exit until after all processes have >>> entered. So taking t2 after the barrier might be a bit misleading, and may >>> cause unexpected skew. >>> >>> >> The barrier exit times are not guaranteed to be uniform, but in practice >> this style of timing is often the best (or only practical) tool one has for >> measuring the collective performance of a group of processes. >> >> Code B *probably* has no effect on time spent between t1 and t2. But >>> extraneous effects might cause it to do so -- e.g., are you running in an >>> oversubscribed scenario? And so on. >>> >>> >> Right. The bottom line here is that from a causal point of view it would >> seem that B should not impact the timings. Presumably, some other variable >> is actually responsible here. > > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users >
