On Tue, 16 Mar 2010, John Peterson wrote:
On Tue, Mar 16, 2010 at 1:27 PM, Roy Stogner <[email protected]> wrote: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?
I don't think it was - or at least in hindsight I can't think of any rationale. If you'd commit the barrier logging to svn after you add it I'd appreciate that. Thanks, --- Roy
------------------------------------------------------------------------------ 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
