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

Time measurement #17

Open
elisabeth96 opened this issue Aug 25, 2021 · 8 comments · May be fixed by #1179
Open

Time measurement #17

elisabeth96 opened this issue Aug 25, 2021 · 8 comments · May be fixed by #1179
Assignees
Labels
class::discussion Used for discussions on software and model . class::performance Performance related issues model::abm This issue concerns any kind of agent-based model. model::ode This issue concerns any kind of ODE-based model. prio::moderate The priority of this task is moderate.

Comments

@elisabeth96
Copy link
Contributor

elisabeth96 commented Aug 25, 2021

In order to better detect bottlenecks or time consuming code parts, time measurement should be enabled / integrated. The question remains how we would like to do this. A simple option would be via OpenMP but this would be that it gets deactivated once the project is not build with OpenMP by a user.

Any better suggestions @dabele @joergbrech ?

(Text added by @mknaranja)

@elisabeth96 elisabeth96 added prio::moderate The priority of this task is moderate. class::discussion Used for discussions on software and model . model::abm This issue concerns any kind of agent-based model. model::ode This issue concerns any kind of ODE-based model. labels Aug 25, 2021
@dabele
Copy link
Member

dabele commented Sep 22, 2021

please add a description to what should be done/discussed.

@mknaranja
Copy link
Member

mknaranja commented Oct 6, 2021

@dabele
Copy link
Member

dabele commented Oct 6, 2021

I think this still needs refinement before we can estimate it.

The use case is not clear to me. Should it be just a simple stopwatch that can you can add to the code on demand during development, then immediately print the time? Or should it be something that is more advanced? Should it be able to collect multiple measurements and print at the end? Should it support scopes, similar to a profiler? should it be integrated with the logging system or is printing always ad-hoc using whatever way works for debugging? Should it be part of the code constantly, like logging, but deactivateable?

@joergbrech
Copy link
Contributor

Would it make sense to add Google Benchmarks to our CMake Project, sort of like our unit tests?

@mknaranja
Copy link
Member

I think that's another issue. We maybe want to have benchmarks in the future, but I also would like to offer time measurements in normal code execution (like examples), don't you?

@mknaranja
Copy link
Member

mknaranja commented Nov 27, 2022

Generally, we should run our algorithms many times in benchmark situations, in particular as for most algorithms execution time is small!

For further discussion, here is some nice short summary on this topic as first answer: https://stackoverflow.com/questions/20586661/what-should-i-check-cpu-time-or-wall-time or https://service.futurequest.net/index.php?/Knowledgebase/Article/View/407/0/difference-between-cpu-time-and-wall-time

Some notes on plain C++ time measurement:

https://www.geeksforgeeks.org/measure-execution-time-function-cpp/
https://iq.opengenus.org/measure-time-in-cpp/

  • The high_resolution_clock is not implemented consistently across different standard library implementations, and its use should be avoided
  • Class std::chrono::steady_clock represents a monotonic clock. The time points of this clock cannot decrease as physical time moves forward and the time between ticks of this clock is constant. This clock is not related to wall clock time (https://en.cppreference.com/w/cpp/chrono/steady_clock)
  • Class std::chrono::system_clock represents the system-wide real time wall clock. It may not be monotonic: on most systems, the system time can be adjusted at any moment. It is the only C++ clock that has the ability to map its time points to C-style time. (https://en.cppreference.com/w/cpp/chrono/system_clock)

For measuring wall-clock time with OpenMP:

https://www.openmp.org/spec-html/5.0/openmpsu160.html

@dabele
Copy link
Member

dabele commented Nov 28, 2023

Closed by #756

@dabele dabele closed this as completed Nov 28, 2023
@github-project-automation github-project-automation bot moved this from Product Backlog to Done (Sprint) in MEmilio: Agent-Based-Model Development Nov 28, 2023
@github-project-automation github-project-automation bot moved this from Product Backlog to ✅ Done (Sprint) in MEmilio: Equation-Based-Models Development Nov 28, 2023
@mknaranja
Copy link
Member

@dabele I am reopening the issue as (at least after some iterations) understood the issue as more general, i.e., to implement a timing scheme for all models that can be activated/deactivated or changed in granularity for all simulations.

@mknaranja mknaranja reopened this Nov 28, 2023
@github-project-automation github-project-automation bot moved this from ✅ Done (Sprint) to Sprint Backlog in MEmilio: Equation-Based-Models Development Nov 28, 2023
@github-project-automation github-project-automation bot moved this from Done (Sprint) to Development in MEmilio: Agent-Based-Model Development Nov 28, 2023
@mknaranja mknaranja moved this from Development to EPIC in MEmilio: Agent-Based-Model Development Nov 28, 2023
@mknaranja mknaranja moved this from Sprint Backlog to Epics in MEmilio: Equation-Based-Models Development Nov 28, 2023
@reneSchm reneSchm linked a pull request Jan 9, 2025 that will close this issue
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
class::discussion Used for discussions on software and model . class::performance Performance related issues model::abm This issue concerns any kind of agent-based model. model::ode This issue concerns any kind of ODE-based model. prio::moderate The priority of this task is moderate.
Projects
Development

Successfully merging a pull request may close this issue.

4 participants