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

Current hardware trends make C++ exceptions harder to justify

open-std.org

Post reply on HN
Print view View original

411–420 of 516 posts

Re: Current hardware trends make C++ exceptions harder to justify

#411

Post by atq2119 »

kllrnohj wrote: post #324
jerf wrote: post #113

Earlier quoted context omitted.

I kinda look to when the thing finally stabilizes as a sign as to how bad the problem was. For instance, Javascript front end was a nightmare for a long time, but it seems to have finally stabilized into a reasonable stable configuration with a couple of winners, some minor specialized choices, and the endless churn is now a minor sideshow instead of something that is changing the default choice every six months. The…

> it still seems like "best practices" on C++ are churning around 1.5-2 years, it's been happening for my entire career, and it's still happening I have to disagree with this quite strongly. What "best practices" churn are you seeing? Your reference example of "don't use new & delete" (which I agree with) was a single best practice change that happened ~10 years ago. Similarly https://isocpp.github.io/CppCoreGuidelin…

I think you're mostly right, but there is a bunch of fluctuation around just how much ugly template magic you're supposed to use vs. plain old imperative control flow (, ranges, I'm looking at you!)

Re: Current hardware trends make C++ exceptions harder to justify

#412

Post by atq2119 »

JAlexoid wrote: post #142
jerf wrote: post #113

Earlier quoted context omitted.

I kinda look to when the thing finally stabilizes as a sign as to how bad the problem was. For instance, Javascript front end was a nightmare for a long time, but it seems to have finally stabilized into a reasonable stable configuration with a couple of winners, some minor specialized choices, and the endless churn is now a minor sideshow instead of something that is changing the default choice every six months. The…

One of the reasons why I try to avoid C++ is that it's an unopinionated multi paradigm kitchen sink language. There are great uses and great features, but there are so many of them and everyone has their own opinions.... Even in this thread there's a clear subset of people who "adore" C++ exceptions

C++ is opinionated, just not in the same way as other programming languages. That is its strength.

(Perhaps the clearest C++ opinion is "zero cost abstractions")

Re: Current hardware trends make C++ exceptions harder to justify

#413

Post by talaketu »

gumby wrote: post #392
talaketu wrote: post #369

Earlier quoted context omitted.

English also has the phrase "the exception proves the rule" - and it's just swell when our general code handles special cases. I would have not have thought an unreachable host was exceptional, given that it's quite normal.

In this aphorism, “prove” has an archaic meaning: “ tests the rule”. The point is that handling the host unreachable is almost always semantically higher level than the code opening the connection. This the code opening doesn’t implement the policy of what to do when the situation occurs. In the case, say, of a hard-coded address then it’s possible the author of that piece of code does know how to handle a host unrea…

Yes, this is said, but the meaning of "prove" (which is related to "probe") has not really changed very much at all compared to "test" - a word which in this sense is a metonym from the fired pot used for assay of metal. The meaning in "mathematical proof" or "prove beyond reasonable doubt" or "prove your love" doesn't really diverge significantly from this so-called archaic meaning - a demonstration to show.

On the software abstraction, exceptions are simply a convenient implicit control flow device for handling the alternate path when an intended state cannot be achieved. I don't follow the paper's argument that "current exception design is suboptimal for efficient implementation" - but I would not be surprised considering the lifetime issues.

Re: Current hardware trends make C++ exceptions harder to justify

#414

Post by pjmlp »

pyjarrett wrote: post #385
pjmlp wrote: post #291

Earlier quoted context omitted.

FPS rate should not drive what 99% of other C++ developers are able to use the language for.

A lot of C++ developers outside of games don't use exceptions. It introduces a latent and hidden goto up the call chain in your code, and require additional bookkeeping by the program which slows things down. They're also dangerous when you update code because if you introduce a new exception in a function you need to update all of the call-sites. When doing this with monads or sum types, this refactor can be support…

And many more of them do use them.

Unfortunely C++ suffers from having people that are so crazy about performance, yet never bother to learn how to use a profiler.

That is what boggles my mind, how one can be writing C++ as if they were fitting Assembly into 8 bit home computers, but never bother to learn how to use something like V-Tune.

By the way, there are other languages besides Ada with exceptions used for systems programming, and if they aren't as big as C++ it is only due to how market adoption has evolved, which had lots of factors not "does the language do exceptions".

CLU, Cedar, Modula-2, Modula-3, Object Pascal, D

Re: Current hardware trends make C++ exceptions harder to justify

#415

Post by ncmncm »

randyrand wrote: post #399
ncmncm wrote: post #397

Earlier quoted context omitted.

This just spectacularly bad advice and policy. Point performance is the worst way to decide about error handling. The overlap between "things that fail and the caller knows something useful to do", and "things that fail and somebody maybe six levels back in the call chain might know something to do" is remarkably thin. Most things are the latter. Once in a while, it makes sense to provide one for each: (1) open a fil…

> Point performance is the worst way to decide about error handling. My point is exactly that. It's more important to have a single common way of doing error handling than it is to have a small perf improvement. That's why I recommend return values. You'll never hit a perf problem with them. Exceptions cannot be used in code hot paths (~thousands of iterations) when it's not a small perf problem anymore. Therefore, t…

Without exceptions, you will hit a performance problem on every single call, successful or not. That is what happens at Google, and in Rust: almost every last call site in the whole system has a "if" check. I.e., it is both badly obscured, and also slow.

You are arguing that programmers should not be obliged to make judicious choices. But that is exactly the job of every programmer. Dodging consequential choices practically defines a bad programmer.

Your assertion that destructors handle errors reported by return value is disingenuous, if not actively dishonest. The code checking for and acting on a failure is not in a destructor, and is never exercised except when you succeed in provoking exactly that failure.

You are writing bad code, and should be ashamed.

Re: Current hardware trends make C++ exceptions harder to justify

#416

Post by astrange »

ncmncm wrote: post #357
astrange wrote: post #218

Earlier quoted context omitted.

Using up BTB slots is an interesting problem but in practice doesn't seem to be a big issue. If it was, ISAs would use things like hinted branches but instead they've been taking them away. Code size is more important but hot/cold splitting can help there. A problem with using exceptions instead is they defeat the return address prediction by unwinding the stack.

That hinted branches are not useful tells us nothing about the importance of branch predictor footprint. When hinting branches gives you a bigger L1 cache footprint, it has a high cost. Compilers nowadays use code motion to implement branch hinting, which does not burn L1 cache. (Maybe code motion is what you mean by "hot/cold splitting"?) Anyway the hint we really need, no ISA has: "do not predict this branch". (We…

> When hinting branches gives you a bigger L1 cache footprint, it has a high cost.

It was the same size on PPC, and on x86 using recommended branch directions (but not prefixes).

> Compilers nowadays use code motion to implement branch hinting, which does not burn L1 cache. (Maybe code motion is what you mean by "hot/cold splitting"?)

Hot/cold splitting is not just sinking unlikely basic blocks, it's when you move them to the end of the program entirely.

That doesn't hint branches anymore, though; Intel hasn't recommended any particular branch layout since 2006.

> How does using exceptions defeat return address prediction? You are explicitly not returning, so any prediction would be wrong anyway.

Anything that never returns is a mispredict there; most things return. What it does instead (read the DWARF tables, find the catch block, indirect jump) is harder to predict too since it has a lot of dependent memory reads.

Re: Current hardware trends make C++ exceptions harder to justify

#417

Post by ncmncm »

Koshkin wrote: post #352
zozbot234 wrote: post #344

Earlier quoted context omitted.

Not sure I get your point - the exact same is true of a C function which is passed a void* ctx object, since those objects have to be allocated and their lifecycle has to be managed. It's still a zero overhead feature.

The (potential) overhead lies with 'ctx' of course. The lambda syntax makes it all too easy to forget about it.

A pointer argument passed in a register is not what we mean when we say "overhead".

Without the lambda, you would instead need to pass the pointer manually, for identically the same cost. But then the compiler would not understand as well what you were doing, and would be unable to optimize it as well. Here, the lambda gives you negative overhead, vs. what you would have written.

Re: Current hardware trends make C++ exceptions harder to justify

#418

Post by mcronce »

randyrand wrote: post #337
tremon wrote: post #329

Earlier quoted context omitted.

They should be used when standard return value errors are measured to be impacting perf (ie. exceedingly rarely) I disagree with this. I think they should be used whenever "standard" return value error handling starts to obfuscate the normal operation (happy flow) of the code. This impact on developer performance happens a lot sooner than the measurable machine performance.

It should not obfuscate the happy path. In rust, propagating an error up is as easy as adding a '?' after the function call. fn read() -> Result { let f = File::open("hello.txt")?; // propgate up? let s = f.read_to_string(&mut s)?; // propgate up? Ok(s) }

Until getting the ? operator in Rust, I always thought I really liked exceptions. After all, what was the alternative? `if err != nil { return nil, err }` everywhere just to propagate errors up and probably ultimately have the process panic when there's an error? "How obnoxious", I thought; the vast majority of the time I'd rather crash and be restarted than attempt to recover and risk severely corrupting state.

Turns out I strongly prefer explicit errors over exceptions, I just also strongly prefer error handling not consuming 75% of the lines on my screen.

And in the cases where I really do prefer a panic, there's always `.unwrap()`

Re: Current hardware trends make C++ exceptions harder to justify

#419

Post by grandinj »

passivate wrote: post #221
grandinj wrote: post #90

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on a profile, let alone become a problem. I think this paper started with a conclusion, and worked backwards to justify it.

Do you still have any notes from your profiling?

I gave talks at the Libreoffice conference in 2019 https://www.youtube.com/watch?v=QnBIeeBZf70 and in 2021 https://www.youtube.com/watch?v=VbL6mXXnFdo&list=PL0pdzjvYW9...

Re: Current hardware trends make C++ exceptions harder to justify

#420

Post by tsimionescu »

yakkityyak wrote: post #19
tsimionescu wrote: post #8

Very interesting that exceptions have much less overhead on the happy path than Rust/Haskell style Either types (std::expected): > For fib we see a slowdown of approx. 60% compared to traditional exceptions, which is still problematic.

I'm not convinced a recursive implementation of `fib` is a reasonable example to draw such a conclusion.

The article explains that they close that as a simple example of a workflow that is heavy on function calls.
Post reply on HN