[deng]

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.

[neutronicus]

> 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

[deng]

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]

I'm confused. Are you suggesting that Fortran is a good environment for game development?

[vlovich123]

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]

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]

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]

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.

[cheez]

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