Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Sad State of Debug Performance in C++

vittorioromeo.info

Post reply on HN
Print view View original

91–100 of 111 posts

Re: The Sad State of Debug Performance in C++

#91

Post by titzer »

olliej wrote: post #78
titzer wrote: post #24

Earlier quoted context omitted.

The phrase "zero-cost abstraction" is a lie anyway. It's all relative to how much compiler optimization happens. If you actually executed the C++ specification step by step, the code would be dog slow, because there are so many implicit conversions, constructions, inlining, constant folding, etc. We could quibble about how much static resolution qualifies (template expansion, overload resolution, etc--that's executin…

If you implemented any language following the spec in a step by step manner they would be dog slow, because any usable spec has to be very explicit in every step required for every operation. All those conversions that you believe only happen if you implement the spec “step by step” always happen. Actual implementations of languages then implement the explicitly described semantics, in whatever way they feel is most…

Bah. Compiling Java to bytecode consists of a lot of static resolution steps and then a fairly straightforward, simple translation. Single-stepping the bytecodes will absolutely produce the same results as the optimized JIT code and there are few expressions that generate more than 1 to a handful of bytecodes.

Re: The Sad State of Debug Performance in C++

#92

Post by rowanG077 »

nice_byte wrote: post #86
deadbeeves wrote: post #79

Earlier quoted context omitted.

>It's actually less predictable than a GC that you can run manually at fixed intervals or whenever a convenient opportunity arises. Not really. It's difficult to reason about, but it's entirely deterministic, unlike a tracing GC.

when you cross a certain level of complexity, the deterministic nature becomes a Turing tarpit of sorts: yes, it's "deterministic", but the number of factors affecting the behavior is so large and their interactions so complex that it might as well be "non-deterministic" -- it's impractical to reason about in detail.

I disagree. The big point of the determinism is that you can actually trivially control when deallocation occurs. In fact even if you don't want to manually reason about there are tools which can graphically show you when objects are deallocated.

Re: The Sad State of Debug Performance in C++

#93

Post by the-lazy-guy »

MauranKilom wrote: post #69
the-lazy-guy wrote: post #50

Earlier quoted context omitted.

std::move is not only about performance. It is about being able to disallow destructive copies of certain types. I.e. unique_ptr can not be copied, and auto_ptr can. Can you write perfectly functioning code without these features? Sure! You just have to be accurate. Same with performance. Where nowadays simple std::move() on a return value suffices you had previously explicitly to pass the object/vector with which yo…

Note that you don't even have to std::move a return value in almost all cases. (The very much non-language-lawyer explanation is that local variables are automatically moved from when you return them.)

Yep, you don't, as long as you want to return a local object. I know that copy elision for returns is not a permitted optimization anymory but a mandatory behavior (since C++11?). And it is a common pitfall to use unnecessary std::move calls which inhibit optimizations.

But if you have something like a builder object which builds a thing which it keeps as an instance variable; then you have to use `return std::move()` or an out-parameter-and-swap if you want to avoid copies.

Re: The Sad State of Debug Performance in C++

#94

Post by triknomeister »

gumby wrote: post #81
gernb wrote: post #44

Earlier quoted context omitted.

It'd maybe be nice to be able to mark which code gets optimized. If I could make all std as "don't debug this and keep it optimized" I would. I know some debuggers have the option to at least not step into certain code that that doesn't solve the optimization issue

You don't have to compile every file with the same flags. You can vary them with each invocation of the compiler, so trivially get what you want at the translation unit level.

And get equivalent of ODR errors.

Re: The Sad State of Debug Performance in C++

#95

Post by fluoridation »

nice_byte wrote: post #86
deadbeeves wrote: post #79

Earlier quoted context omitted.

>It's actually less predictable than a GC that you can run manually at fixed intervals or whenever a convenient opportunity arises. Not really. It's difficult to reason about, but it's entirely deterministic, unlike a tracing GC.

when you cross a certain level of complexity, the deterministic nature becomes a Turing tarpit of sorts: yes, it's "deterministic", but the number of factors affecting the behavior is so large and their interactions so complex that it might as well be "non-deterministic" -- it's impractical to reason about in detail.

I'll take the "almost non-deterministic" over the non-deterministic. Computers are very good at reasoning about complex deterministic systems.

Re: The Sad State of Debug Performance in C++

#96

Post by bluGill »

properparity wrote: post #53
bluGill wrote: post #19

I'm with Kernigham and Pike: the debugger is for getting a stack trace out of core dumps. Printf is for debugging.

Why limit yourself to crusty text when you can have live visualizations of data structures in various formats, graph dx/dy over time of some variable, stop and inspect data on some condition without having to modify code, quickly start execution on a certain line, quickly drill down into struct members, etc. I mean it does everything a printf() can do - except just better.

The one thing printf does better is force me to stop and think about why.

I find that when I use a debugger I fall into the trap of mindless looking at variables, stopping to inspect data (sometimes changing a variable), drilling down into struct members... (That is your exact list except I've never used a debugger that can graph dx/dy though I'm sure that applies too) All the while forgetting that the real goal is to figure out why the program is in the bad state i the first place.

If you can avoid that trap all those tools of debuggers are useful. I sometimes do use a debugger for each of the above things, but I make it a point to limit the time I spend in the debugger.

Re: The Sad State of Debug Performance in C++

#97

Post by dannas »

dannas wrote: post #10
DannyBee wrote: post #5

Earlier quoted context omitted.

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…

[gcc/gdb/LLVM outsider here] If someone is interested in what's being done to improve LLVMs debuginfo, here's a talk by Djordje Todorovic from two years ago: https://www.youtube.com/watch?v=GpMLt1oecOk . It's about tracking dwarf locations for variables by keeping around information from the parent frame. According to that presentation, at least that work has been progressing.

As for contributions from the gamedev industry, here's a EuroLLVM 2022 presentation from Orlando Cazalet-Hyams working at Sony: https://www.snsystems.com/technology/tech-blog/improving-deb...

Re: The Sad State of Debug Performance in C++

#99

Post by jjtheblunt »

bluGill wrote: post #89
jjtheblunt wrote: post #38

Earlier quoted context omitted.

oh where is that quote? that's great!

In the 'practice of programming'. https://www.cs.princeton.edu/~bwk/tpop.webpage/ I last read it some years ago so I can't tell you exactly what they said. I do know that when pointed out I realized I suffer from the same sins they hate about debuggers: I would step through code mindlessly, changing variables and the like, but never stopping to think. While printf is more painful it forces me to think why is the code…

i totally agree

Re: The Sad State of Debug Performance in C++

#100

Post by gumby »

triknomeister wrote: post #94
gumby wrote: post #81

Earlier quoted context omitted.

You don't have to compile every file with the same flags. You can vary them with each invocation of the compiler, so trivially get what you want at the translation unit level.

And get equivalent of ODR errors.

I really doubt flags like -g or -O if going to cause those issues.
Post reply on HN