On Tue, Mar 16, 2010 at 1:27 PM, Roy Stogner <[email protected]> wrote: > > On Tue, 16 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > >> The only other thing that comes to mind is that max effectively >> introduces a barrier > > Very good point. John, you might try sticking Parallel::barrier() in > front of each of the Parallel::max() calls - if that ends up capturing > all the perflog time, then the problem isn't max() taking 24 seconds, > it's max() on one processor waiting for a different processor to > finish up unrelated work. In which case it's not our Parallel::max > implementation that's screwed up, just our load-balancing. ;-)
OK, I will try this and let you know the results. By the way, there appears to be no logging in Parallel::barrier()... was that a conscious choice? -- John ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
