Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor handling of timers to achieve simpler code in place of use and increase coverage #3098

Open
heplesser opened this issue Feb 8, 2024 · 1 comment
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: Normal Handle this with default priority stale Automatic marker for inactivity, please have another look here T: Enhancement New functionality, model or documentation
Projects

Comments

@heplesser
Copy link
Contributor

Currently, timers in NEST are typically started/stopped with code like this:

  if ( tid == 0 )
  {
    sw_communicate_prepare_.start();
  }

or

#ifdef TIMER_DETAILED
  if ( tid == 0 )
  {
    sw_gather_target_data_.start();
  }
#endif

This creates a lot of visual clutter and is not as expressive as it could be in terms of OpenMP. I suggest the following:

  1. All if ( tid == 0 ) should be replaced by #pragma omp master, which should have the same effect and does not introduce barriers.
  2. We should try to move both this pragma and the #ifdef TIMER_DETAILED into the start()/stop() methods. These should be inline, so that this should not cause any overhead. It will require creating a Stopwatch subclass for DetailedStopwatch, which is inactive unless the detailed timers option is set.
  3. Add detailed timers for gathering and delivering secondary events #3097 adds coverage for secondary event time. We should also add detailed timers for MUSIC, WFR, and Structural Plasticity (in two places) so that we have all parts of the update loop covered.

This work will required careful benchmarking to ensure that 1 & 2 do not cause longer runtimes.

@heplesser heplesser added T: Enhancement New functionality, model or documentation S: Normal Handle this with default priority I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) labels Feb 8, 2024
@terhorstd terhorstd added this to To do (open issues) in Kernel via automation Feb 19, 2024
Copy link

github-actions bot commented Apr 9, 2024

Issue automatically marked stale!

@github-actions github-actions bot added the stale Automatic marker for inactivity, please have another look here label Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: Normal Handle this with default priority stale Automatic marker for inactivity, please have another look here T: Enhancement New functionality, model or documentation
Projects
Kernel
  
To do (open issues)
Development

No branches or pull requests

1 participant