3 ms·

Would be nice to offer runtime enable/disable. Out of curiosity, I wrote a little benchmark and submitted as a PR: https://github.com/sharkdp/dbg-macro/pull/57

by asah 7y ago

Would be nice to offer runtime enable/disable. Out of curiosity, I wrote a little benchmark and submitted as a PR: https://github.com/sharkdp/dbg-macro/pull/57 https://github.com/sharkdp/dbg-macro/pull/57 The key idea is that modern CPUs dynamically branch-predict-away if-statements that are rarely/never invoked, such as a dynamically disabled dbg() call. With the performance difference magnified 10x by loop unrolling, this is what I'm seeing on my Mac laptop: 830000000 iterations in 3 secs = 2.76667e+08 iters/sec (compiled-out). 840000000 iterations in 3 secs = 2.8e+08 iters/sec (dynamically disabled). And this is the worst case, where the whole program does nothing but call dbg() - real world programs contain lots of other real work, drowning the minute difference in performance, i.e. in a real program I doubt you'd see even 0.1% total performance difference, littering it with dynamic dbg() statements. p.s. my C/C++ is pretty rusty - feedback welcome, but pls be kind.

xiphias2 7y ago
This is not a real disabling of dbg. dbg.h should support a function that disables writing out to the screen, but still returning the expression during run-time. You could try it out with something like this: disable_dbg_output(); int a = 0; for(int i=0; i<1000000000; i++) { a += dbg(i); }
- asah 7y ago
  yes, correct - my code is just the performance test, which IMHO is the first step and surprisingly tricky due to effects from the loop around it. The code for dynamic enable/disable is trivial but the design is a bit subjective. For example, another API might be set_dbg_output(bool) and then maybe get_dbg_output() to inspect the current state.
  - pnako 7y ago
    An alternative route might be to find a way to integrate this code with a logging library like spdlog. This way you'd get the cool short notation of dbg(...) and the ability to have more control about the sinks (including indeed dynamic disabling/enabling).
jnordwick 7y ago
That probably closer to a best case scenario. A property predicted branch is still an extra instruction and a couple of entries in the branch target buffer and a global(?) history (I'm not really up to date on the newer perceptron predictors yet. These are going to be limited resources so you'd rather not pollute them and make other branches predict wrong because they are aliases (shared) by many different instruction address. Also, the fetcher can only get instructions in blocks and if there are multiple branches it will have to predict based on the first branch. There is a lot of machinery in branch and branch the prediction because keeping the pipeline full of instructions is critically important for performance. And while throuhput may not suffer much, the chances of increasing mispredictions in the hot path increase adversely harming latency. These really need to be compiled out for release because you can't assume others can afford the cycles.

by asah 7y ago

xiphias2 7y ago

This is not a real disabling of dbg. dbg.h should support a function that disables writing out to the screen, but still returning the expression during run-time. You could try it out with something like this: disable_dbg_output(); int a = 0; for(int i=0; i<1000000000; i++) { a += dbg(i); }

asah 7y ago
yes, correct - my code is just the performance test, which IMHO is the first step and surprisingly tricky due to effects from the loop around it. The code for dynamic enable/disable is trivial but the design is a bit subjective. For example, another API might be set_dbg_output(bool) and then maybe get_dbg_output() to inspect the current state.
- pnako 7y ago
  An alternative route might be to find a way to integrate this code with a logging library like spdlog. This way you'd get the cool short notation of dbg(...) and the ability to have more control about the sinks (including indeed dynamic disabling/enabling).

jnordwick 7y ago

That probably closer to a best case scenario. A property predicted branch is still an extra instruction and a couple of entries in the branch target buffer and a global(?) history (I'm not really up to date on the newer perceptron predictors yet. These are going to be limited resources so you'd rather not pollute them and make other branches predict wrong because they are aliases (shared) by many different instruction address. Also, the fetcher can only get instructions in blocks and if there are multiple branches it will have to predict based on the first branch. There is a lot of machinery in branch and branch the prediction because keeping the pipeline full of instructions is critically important for performance. And while throuhput may not suffer much, the chances of increasing mispredictions in the hot path increase adversely harming latency. These really need to be compiled out for release because you can't assume others can afford the cycles.