3 ms·

Interesting! My baseline expectation would be that this wouldn't work at all, debugging C++ usually tells me variables have been removed by the optimiser. Perha

Interesting! My baseline expectation would be that this wouldn't work at all, debugging C++ usually tells me variables have been removed by the optimiser. Perhaps this requires `-O0 -g` or similar to work effectively, which games devs are usually not open to. Optimising IR without dropping debug info is difficult. I don't believe it to be intractable, some of the Sony developers are active in improving this for LLVM. Debug info is roughly a bunch of side tables of data from which one can recompute values which were in the original program and are not in the executing one. I would speculate that a compilation mode which treated any degradation of that as a miscompile could be done with minor to no runtime cost, at serious engineering cost. Perhaps easier would be to restructure the program so that specific variables are always available to the debugger. Deliberately hoist them to escaped global variables, roughly. The other interesting line of attack here is a JIT. The students probably don't change all the parameters simultaneously. Call graph walk + incremental compilation of parts affected by a given variable is probably tractable. A sibling mentioned hot code replacement, that's a similar sort of hack (you block function inlining, pad functions with some nops, then overwrite in place if the new definition fits in the space). Thanks for the link, interesting stuff.

Karliss 3y ago
> Perhaps this requires `-O0 -g` or similar to work effectively, which games devs are usually not open to. There are also plenty of game devs expressing the idea of "never use STL, because that makes performance unusable in debug builds". Which implies that many of them are not completely against debug builds (for debug/development purpose). The problem of variables being optimized away is mostly for local variables. This tool will most likely used on global/long lifetime objects representing overall game state and configuration, instead of temporary variables while stepping through a function. (used)Global variables and class properties are unlikely to be optimized away or mangled in away that makes them hard to inspect. This was created to help students while learning. In those kinds of projects performance is somewhat to be less of an issue, unless you make a mistake which would ruin performance regardless of optimization level.
dualogy 3y ago
> Perhaps this requires `-O0 -g` or similar to work effectively, which games devs are usually not open to. Well, not for the shipping/release/prod builds, sure. But for dev? I dunno, from my vantage would rather keep it, if not for debug/inspect then just for compile speeds and ensuring a certain baseline perf even-without-optimizations... (but then, I'm not triple-A or have any games to my record =)

Karliss 3y ago

> Perhaps this requires `-O0 -g` or similar to work effectively, which games devs are usually not open to. There are also plenty of game devs expressing the idea of "never use STL, because that makes performance unusable in debug builds". Which implies that many of them are not completely against debug builds (for debug/development purpose). The problem of variables being optimized away is mostly for local variables. This tool will most likely used on global/long lifetime objects representing overall game state and configuration, instead of temporary variables while stepping through a function. (used)Global variables and class properties are unlikely to be optimized away or mangled in away that makes them hard to inspect. This was created to help students while learning. In those kinds of projects performance is somewhat to be less of an issue, unless you make a mistake which would ruin performance regardless of optimization level.

dualogy 3y ago

> Perhaps this requires `-O0 -g` or similar to work effectively, which games devs are usually not open to. Well, not for the shipping/release/prod builds, sure. But for dev? I dunno, from my vantage would rather keep it, if not for debug/inspect then just for compile speeds and ensuring a certain baseline perf even-without-optimizations... (but then, I'm not triple-A or have any games to my record =)