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

Create a mechanism for turning the profiler off #4

Open
Tracked by #2
andrewcoughtrie opened this issue Nov 3, 2021 · 1 comment
Open
Tracked by #2

Create a mechanism for turning the profiler off #4

andrewcoughtrie opened this issue Nov 3, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@andrewcoughtrie
Copy link
Collaborator

andrewcoughtrie commented Nov 3, 2021

Create a mechanism for turning the profiler off (Useful to sort out early on, so that it doesn't become difficult to add later.) e.g. A const logical/boolean so that they are removed by optimising compilers.

Will need looking into, unsure exactly what the requirements are, @mo-mglover can you provide more detail.

@andrewcoughtrie andrewcoughtrie mentioned this issue Nov 3, 2021
8 tasks
@andrewcoughtrie andrewcoughtrie changed the title Has a mechanism for turning the profiler off been devised and tested? (Useful to sort out early on, so that it doesn't become difficult to add later.) e.g. A const logical/boolean so that they are removed by optimising compilers. Create a mechanism for turning the profiler off Nov 3, 2021
@andrewcoughtrie andrewcoughtrie added the enhancement New feature or request label Nov 3, 2021
@mo-mglover
Copy link
Collaborator

mo-mglover commented Nov 5, 2021

DrHook contains a logical (lhook), which determines whether callipers are called at all. i.e. This logical is exposed to the calling program, and used in if tests by the calling program. This has the benefit that one only has to compile with lhook as a compile-time constant, set to false, and any optimising complier will magically remove the callipers; therefore, zero performance overhead when not in use.

This approach would be OK, but I'm sure we can do better. Questions to consider:

  • Do we want different "levels" of logical, so that the profiler can be activated by, say large routines but off for very small functions/subroutines?
  • Do we want different logicals for different code sections?
  • If we do use logicals in this way, does the complier correctly optimise them away when set at compile-time? [I would assume this is true, and I'm confident of this with Fortran compilers, but best not to make assumptions.]
  • Is there a case for CPP'ing them in? If we do, I'd insist on each macro occupying and pre-processing to a single line. (I'm normally minded to avoid CPP macros, but I won't discount them too early.)

Whatever we do, I think it's important to retain the ability to turn it off when compiled in. And the logical/boolean switches would need to be global, so it makes sense to build them into the profiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants