On 29 Jan 2014, at 10:11, Leo Brewin <[email protected]> wrote: > Hi Roland and Frank, > > I'm very grateful for the quick replies but unfortunately there must be some > other issue at play here. I'm running Cactus 4.2.0 and I compiled it on 14 > Sep 2013 (from the ET_2013_05 source). I've looked into the source of > LoopControl and it doesn't have "settle_after_iteration" (so the fix > suggested earlier simply produces a parse error in the .par file). > > Any other thoughts?
Any timer which includes communication has to be interpreted very carefully. The communication call first has to wait for other processes involved in the communication to catch up to the same point in the code. If there is an imbalance in the time spent in a particular function on different processes (e.g. due to having a slightly different grid size, or some work being performed only by one process), then this extra time will be included in the timer of the routine waiting to communicate. You can get a better idea of what is going on by introducing "barriers" between each function. These are calls which explicitly wait for other processes to catch up. These are timed separately, so you can measure the time spent due to imbalance, and distinguish it from the time spent doing actual work. Carpet::schedule_barriers = "yes" Carpet::sync_barriers = "yes" Another useful parameter is Carpet::output_timer_tree_every = 32 which shows a hierarchical view of the largest timers on standard output. I recommend that everyone enable this parameter, as it provides a very quick way to see the breakdown of the run performance at a glance, including the information about which timers are contained within other timers. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
