21–30 of 111 posts
1. Compile time
2. Non-optimized builds
Stuffing everything into the Standard Library using lots of template magic does has its upside, but debug performance is one of the big downsides.
Another one are really clunky interfaces, like std::variant. This should really have been a language feature, not a library features.
> Even if -Og was ubiquitous, it is still suboptimal to -O0: it can still inline code a bit too aggressively for an effective debugging session. IMO, the problem is not so much the inlining, but the sad state of the optimization passes losing track of many things and producing useless debug info.
Eons ago, i wrote a lot of the first version of debug location tracking/location list tracking in GCC, and the support for evaluating them in GDB (plenty of others came along and improved it nearly instantly - it thankfully did not last long alone ;P). I have spent, over the years, an amazing amount of time on trying to improve optimized-code debug info. You could and should improve the optimization passes, but at va…
Person slightly doing things to LLVM checking in -- the three points you list are compelling, because it's always going to be difficult to describe one program (source) in terms of a vastly different (optimised) program. Do you think there's mileage in showing the developer a partially optimised program [0] instead of trying to perfectly describe the source? It'd be easier to describe in debug-info, and possibly easier for developers to identify unexpected changes to the code they wrote.
[0] "Non-Transparent Debugging of Optimized Code", 1999
> Even if -Og was ubiquitous, it is still suboptimal to -O0: it can still inline code a bit too aggressively for an effective debugging session. IMO, the problem is not so much the inlining, but the sad state of the optimization passes losing track of many things and producing useless debug info.
Eons ago, i wrote a lot of the first version of debug location tracking/location list tracking in GCC, and the support for evaluating them in GDB (plenty of others came along and improved it nearly instantly - it thankfully did not last long alone ;P). I have spent, over the years, an amazing amount of time on trying to improve optimized-code debug info. You could and should improve the optimization passes, but at va…
This is apparent in C++ when you look at the optimized output on Compiler Explorer: it attempts to color assembly based on the source lines, and some source lines get strewn about the resulting assembly.
The problem is that C++ is full of so called "zero-cost-abstractions" that are only zero cost if you ignore: 1. Compile time 2. Non-optimized builds Stuffing everything into the Standard Library using lots of template magic does has its upside, but debug performance is one of the big downsides. Another one are really clunky interfaces, like std::variant. This should really have been a language feature, not a library…
> Even if -Og was ubiquitous, it is still suboptimal to -O0: it can still inline code a bit too aggressively for an effective debugging session. IMO, the problem is not so much the inlining, but the sad state of the optimization passes losing track of many things and producing useless debug info.
Eons ago, i wrote a lot of the first version of debug location tracking/location list tracking in GCC, and the support for evaluating them in GDB (plenty of others came along and improved it nearly instantly - it thankfully did not last long alone ;P). I have spent, over the years, an amazing amount of time on trying to improve optimized-code debug info. You could and should improve the optimization passes, but at va…
JVMs move heaven and Earth to make optimization not observable and support the JVMTI, upon which debuggers are built. They are required to materialize a bytecode-level view of execution state upon demand, just as CPUs are required to materialize a machine-level view of execution state. As a result, any source debugger written against what is available at the bytecode level will work without needing to see through the abstractions.
Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.
Not exactly what you were asking, but RAD tried to build a debugger for Linux^1, but the project died. I’ve heard the people at RAD described as hard core old school programmers, so if they struggled with this it must just be a hard problem 1. http://www.radgametools.com/debug.htm
That article is ~10 years old, is that still true?
Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.
These days I rarely build a whole MSVC project as "Debug" without optimization. Instead I enable both optimization and debug information, so I always get call stacks and line-by-line stepping ability. When I end up debugging some file where the optimizations inhibit debuggability, I'll recompile just that compilation unit or library without optimization or inlining.
That said, I agree with the gist of the article that both "zero cost abstraction" and debuggability need to be constantly improved.
Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.
If you're developing for games consoles, you're probably stuck using a specific revision of the compiler offered by the platform owner, even if it happens to be clang under the hood. In some cases their certification requirements entirely prohibit using other compilers. So improved debug performance is probably not in the cards unless you change your code to work around compiler issues.
Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.
That proposition seems risky. If the compiler owners don't accept your pull requests, you risk having to maintain a fork with your changes indefinitely. Also, I suspect like 95%+ of development at game dev studios happens in MSVC. Nothing to change there. Unfortunately pestering the compiler devs about this seems like the optimal approach lol
Also, it's kind of moot. For platforms that use GCC, Clang, etc., the maintainers are OSS communities, so that's how you influence the product in a healthy direction for your projects. To sit back and let things happen is also an option, but then debugging support might not meet your needs, for instance.
Seems like mobile and wasm based platforms exist and don't generally use MSVC. Folks around here might be surprised how effective $1MM/yr in engineer salaries can be in the relatively under-resourced OSS compiler development space.