3 ms·

So, the solution to bad debug performance is essentially YAGNI? I'm afraid that isn't a very convincing argument. If your code is several orders of magnitude sl

by deng 8y ago

So, the solution to bad debug performance is essentially YAGNI? I'm afraid that isn't a very convincing argument. If your code is several orders of magnitude slower in debug mode, then this is a problem. Simply downplaying this with arguments like "single-step debugging is a last resort" or "just write better tests" won't make this problem vanish. Just like exploding compile times are not solved with "just buy Incredibuild". But his argument fits well with C++'s history of finding exceedingly complex solutions for simple problems. Want to have efficient matrix calculation? Well, who needs native support for matrices when you can do the same with expression templates and static polymorphism/CRTP (see: Eigen library). The last section of the article says you either do nothing or you get involved. I'm afraid it is missing the obvious third option: switch to another language which actually supports your use case.

cheez 8y ago
For what it's worth, I only use a debugger when I have a crash.
neutronicus 8y ago
> But his argument fits well with C++'s history of finding exceedingly complex solutions for simple problems. Want to have efficient matrix calculation? Well, who needs native support for matrices when you can do the same with expression templates and static polymorphism/CRTP (see: Eigen library). I have to defend C++ here - "native matrices" is under-specified. In practice, "Matrix" is one of the leakiest abstractions in programming and you have to care about representation and choice of algorithm pretty much from the get-go, and IMO C++ is actually the best available option for managing that complexity, especially when you're solving large systems in parallel (and it's worth pointing out that one of the front-running open-source libs in this space is written in C++[1]). [1] https://github.com/trilinos/Trilinos https://github.com/trilinos/Trilinos
- deng 8y ago
  For many projects you won't need that complexity. You just want to directly map basic matrix operations to the usual BLAS/LAPACK calls. Fortran 90+ does that job well, for instance, and performance will usually be better than a C++ library (yes, I've tested against Eigen and Armadillo, although that was years ago). Combine that with the enormous compile times and the absolute ridiculous error messages for even simplest syntax errors, and I never looked back. Fortran may have a bad rep, but the newer iterations are actually pretty good for that kind of stuff.
  - curlypaul924 8y ago
    I'm confused. Are you suggesting that Fortran is a good environment for game development?
Kenji 8y ago
I never use the debugger for game design, except postmortem to see where the segfault happened. I have an advanced logging mechanism and sprinkle my code with logs. I see everything in the logs. There is no need to use the debugger because I always see what's happening. And I can compile my game without the logs (or disable them at runtime) if I need raw performance. That's how you do modern C++ programming.
vlovich123 8y ago
I'm curious if this comment stays true once you build debug with -Og since that's an actual optimization level now that ensures the code remains debuggable while still applying a meaningful number of optimizations. Most people turn off all optimizations in debug builds but that's silly for 99% of problems unless you're tracking down a potential compiler bug.
- pm215 8y ago
  QEMU briefly used -Og for its debug build setting, but switched back to -O0, because in practice using -Og results in a lot more situations where gdb just says "<optimised out>" rather than being able to tell you the values of variables, arguments in stack backtraces, and so on. If -Og really was "optimize where possible without breaking the debug illusion", that would be great, but in my experience it absolutely was not, and now I'm pretty wary of going back and trying it again when -O0 works just fine for me for debug...
  - vlovich123 8y ago
    What version of GCC/GDB were they using? I've been using GCC/GDB 7 for embedded development and haven't really seen a problem with it. It's also almost a hard requirement because otherwise the generated code is much larger & much slow which impacts the runtime behaviour to a significant extent.
    - pm215 8y ago
      This would have been gcc 5.4.0, as shipped by Ubuntu 16.04. Certainly it's possible that newer gcc do better, but from my point of view if they started out with something that breaks the debug illusion it indicates that their definition of the feature is wildly different from mine. Once bitten, twice shy.

by deng 8y ago

cheez 8y ago

For what it's worth, I only use a debugger when I have a crash.

neutronicus 8y ago

> But his argument fits well with C++'s history of finding exceedingly complex solutions for simple problems. Want to have efficient matrix calculation? Well, who needs native support for matrices when you can do the same with expression templates and static polymorphism/CRTP (see: Eigen library). I have to defend C++ here - "native matrices" is under-specified. In practice, "Matrix" is one of the leakiest abstractions in programming and you have to care about representation and choice of algorithm pretty much from the get-go, and IMO C++ is actually the best available option for managing that complexity, especially when you're solving large systems in parallel (and it's worth pointing out that one of the front-running open-source libs in this space is written in C++[1]). [1] https://github.com/trilinos/Trilinos https://github.com/trilinos/Trilinos

deng 8y ago
For many projects you won't need that complexity. You just want to directly map basic matrix operations to the usual BLAS/LAPACK calls. Fortran 90+ does that job well, for instance, and performance will usually be better than a C++ library (yes, I've tested against Eigen and Armadillo, although that was years ago). Combine that with the enormous compile times and the absolute ridiculous error messages for even simplest syntax errors, and I never looked back. Fortran may have a bad rep, but the newer iterations are actually pretty good for that kind of stuff.
- curlypaul924 8y ago
  I'm confused. Are you suggesting that Fortran is a good environment for game development?

Kenji 8y ago

I never use the debugger for game design, except postmortem to see where the segfault happened. I have an advanced logging mechanism and sprinkle my code with logs. I see everything in the logs. There is no need to use the debugger because I always see what's happening. And I can compile my game without the logs (or disable them at runtime) if I need raw performance. That's how you do modern C++ programming.

vlovich123 8y ago

I'm curious if this comment stays true once you build debug with -Og since that's an actual optimization level now that ensures the code remains debuggable while still applying a meaningful number of optimizations. Most people turn off all optimizations in debug builds but that's silly for 99% of problems unless you're tracking down a potential compiler bug.

pm215 8y ago
QEMU briefly used -Og for its debug build setting, but switched back to -O0, because in practice using -Og results in a lot more situations where gdb just says "<optimised out>" rather than being able to tell you the values of variables, arguments in stack backtraces, and so on. If -Og really was "optimize where possible without breaking the debug illusion", that would be great, but in my experience it absolutely was not, and now I'm pretty wary of going back and trying it again when -O0 works just fine for me for debug...
- vlovich123 8y ago
  What version of GCC/GDB were they using? I've been using GCC/GDB 7 for embedded development and haven't really seen a problem with it. It's also almost a hard requirement because otherwise the generated code is much larger & much slow which impacts the runtime behaviour to a significant extent.
  - pm215 8y ago
    This would have been gcc 5.4.0, as shipped by Ubuntu 16.04. Certainly it's possible that newer gcc do better, but from my point of view if they started out with something that breaks the debug illusion it indicates that their definition of the feature is wildly different from mine. Once bitten, twice shy.