Add timers for Carpet modes

Create issue
Issue #1149 closed
Ian Hinder created an issue

It is currently not possible to determine from the timer output how much time is spent on each refinement level, or in each mode (meta, global, level, singlemap, local).

The branch http://git.carpetcode.org/carpet.git/shortlog/refs/heads/ianhinder/modetimers adds a timer tree which times the time spent in each mode, on each refinement level, and on each map (if desired). This tree is output to standard output after the Evolve timer tree if the Evolve timer tree is being output. Two new parameters are added to control whether to time maps and local mode; these default to "no".

Example output with the default parameters

-----------------------
Percent   t/secs  Timer
-----------------------
100.0%     20.4  meta mode
 99.7%     20.4  |_global mode
 11.9%      2.4  | |_level(0)
  9.4%      1.9  | |_level(1)
 15.6%      3.2  | |_level(2)
 23.1%      4.7  | |_level(3)
 28.6%      5.8  | |_level(4)
 10.8%      2.2  | |_untimed

If the maps and local mode are enabled, the output can look like this:

-----------------------
Percent   t/secs  Timer
-----------------------
 100.0%     38.1  meta mode
  94.9%     36.1  |_global mode
  11.9%      4.5  | |_level(0)
   2.0%      0.8  | | |_map(0)
   1.6%      0.6  | | | |_local
   9.8%      3.7  | | |_untimed
   5.0%      1.9  | |_level(1)
   3.4%      1.3  | | |_map(0)
   3.1%      1.2  | | | |_local
   1.6%      0.6  | | |_untimed
   8.1%      3.1  | |_level(2)
   5.0%      1.9  | | |_map(0)
   4.7%      1.8  | | | |_local
   3.0%      1.2  | | |_untimed
  11.0%      4.2  | |_level(3)
   7.0%      2.7  | | |_map(0)
   6.5%      2.5  | | | |_local
   4.0%      1.5  | | |_untimed
  15.5%      5.9  | |_level(4)
  10.8%      4.1  | | |_map(0)
  10.3%      3.9  | | | |_local
   4.6%      1.7  | | |_untimed
  43.3%     16.5  | |_untimed
   5.1%      2.0  | untimed

OK to merge?

Keyword:

Comments (9)

  1. Ian Hinder reporter
    • removed comment

    The reason I didn't apply this yet is that I'm not sure what will happen with multi-patch. Will we end up with different timers on different processes? For example, suppose process 0 has map 0 and process 1 has map 1. Will all maps be entered at least once on all processes? If the timers are not all the same on all processes, I believe that TimerReport will fail.

  2. Erik Schnetter
    • removed comment

    Feel free to describe such issues when you describe the patch...

    No, not all patches will the traversed on all processes.

  3. Ian Hinder reporter
    • removed comment

    I only thought of it after I submitted the patch, and didn't get around to writing it into the ticket; sorry. I didn't expect someone else to apply the patch, so I didn't think it was urgent.

  4. Ian Hinder reporter
    • removed comment

    With the default parameter settings, the timers for the different maps will not be created, so I think in the end it's not a serious problem.

    We could fix this by ensuring that all processes create timers (but do not start them) for all maps, but I think this is not the right approach, as it makes the "minimum" and "average" reductions fairly useless. Instead, I think we should be moving towards a system where if a timer does not exist on a given process, it is not included in the reductions (e.g. the minimum). That way, we would see the minimum time taken for a given map only on the processes that actually had that map, which is probably what the user wants to see anyway. This would need modifications to TimerReport. I have created #1154 to track this enhancement.

  5. Log in to comment