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

121–130 of 516 posts

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

#121

Post by masklinn »

HelloNurse wrote: post #108
masklinn wrote: post #52

Earlier quoted context omitted.

> I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions. The problem is in that case you get into a probabilistic estimation, which is a nice way to say you roll the dice on your performances: what’s the ratio at which exceptions are too costly or sufficiently cheap? And how does that impact your level of service…

If the program fails too often or too unfairly, why should you blame how such failures are handled? The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception", even if actually thrown exceptions were fast.

> If the program fails too often or too unfairly, why should you blame how such failures are handled?

Because the discussion is about methods of reporting and handling failure?

> The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception"

That makes no sense whatsoever, and doesn't address the question.

And even if a ctor fails at a rate of 0.9, it has to report errors via exceptions, because that's the only mechanism available to ctors.

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

#122

Post by mlinksva »

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.

Thanks a lot for your perf work on LibreOffice, which https://gerrit.libreoffice.org/q/Grandin seems to confirm!

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

#123

Post by erwincoumans »

cyber_kinetist wrote: post #46
worik wrote: post #31

Earlier quoted context omitted.

Why do you use C++ in those domains? Curious as to the decision criteria.

If you need any sort of numerical programming, C++ is basically unmatched. It's fast and efficient (have total control over memory and heap allocations), while able to create complex math abstractions thanks to its template system and operator overloading. For example, Eigen is the only library (not in C++, but in the entire programming space) that can optimize your math expressions at compile-time. You can also perf…

Agreed. Eigen can be relatively slow: in our Tiny Differentiable Simulator, with C++ templatized code, we generate C code using CppAdCodegen (by tracing a sim step) which is easily 5 times faster than the original Eigen code. And together with openmp it runs very fast: Ant OpenAI gym simulation at 2 million steps per second on an AMD Ryzen 3900x at 12 cores/24 threads).

See the (unreadable) generated code from Eigen+CppAd Codegen here: https://github.com/google-research/tiny-differentiable-simul...

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

#124

Post by stickfigure »

zozbot234 wrote: post #86
edflsafoiewq wrote: post #72

Earlier quoted context omitted.

My problems with Result/expected/etc 1. They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. 2. In particular, if a change causes a deeply nested function that used to always succeed to be able to error, the entire path up the call graph needs to get Resultified. 3. Since the caller must be aware of them, generic code generally has to be Result-aware too. 4. The…

> They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. This is not "noise" but needed information. A function that can error out should not have the same signature as one that will never return an error. Similarly, call-site special syntax (like '?' in Rust) helps address the concerns raised by hidden control flow. > Since the caller must be aware of them, gener…

> This is not "noise" but needed information.

That is incredibly domain-dependent. In most general business processing, that information is just noise.

Building a web app? 99.9% of the time, you let exceptions get caught by the http server and return 500 to the client. In a few rare cases where you want to do something else, you catch. If you don't catch, the client still gets 500 - a perfectly acceptable fallback.

Building a GUI app? 99.9% of the time, exceptions in the UI loop should just display an error message to the user in a modal dialog and then get ignored. Sure, you can do something else, but the error dialog is a reasonable fallback.

There is no good reason to torture the whole call stack to accommodate these problem domains.

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

#125

Post by Koshkin »

jerf wrote: post #113
ModernMech wrote: post #51

Earlier quoted context omitted.

This is the great strength and weakness of C++. Increasingly the answer to C++'s rough edges is "We don't do things that way anymore. Everyone does X now", where X is the hot new thing. RAII is the best example I can think of, where some people insist that no one would ever use the "new" and "delete" keywords anymore. Except for all the C++ devs that do, and all the C++ code that exists that does and must be maintain…

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…

> C++ just can't seem to stabilize

It's not like C++ is oscillating. It continues to improve, which is a good thing.

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

#126

Post by addaon »

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.

I wouldn't necessarily expect to see throwing show up on a statistical profile. I would expect to see (and very much have seen) throwing showing up as a huge latency spike, leading to user-visible non-responsiveness. Especially in a cold situation (first throw after launch, or throwing after pages have been ejected), a surprising number of memory pages need to be populated to throw an exception.

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

#127

Post by mibsl »

WkndTriathlete wrote: post #65
jdlshore wrote: post #30

Earlier quoted context omitted.

There are some kinds of errors that can’t be handled locally, but do need to be handled globally, or generically higher in the call chain. Continuing execution after the error occurs will make the problem worse. Exceptions allow you to cease execution without putting an if statement after every function call.

Haskell's IO monad says, "Hi! With me you don't need exceptions and you don't need to put an if statement after every function call."

Haskell's IO monad actually has excellent exception support, including async exceptions and masking them in critical sections.

There are `Maybe` and `Either` and they're great at streamlining error handling in pure code, but when it comes to IO most libraries just throw exceptions (including the standard library).

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

#128

Post by masklinn »

gpderetta wrote: post #101
mikepurvis wrote: post #87

Earlier quoted context omitted.

Yeah I knew I was going to get called out with a Rust comparison. I think the Rust approach basically acknowledges the issue with what C++ did— that automatic initialization is cute but ultimately wasn't worth what it ended up costing in terms of hidden control flow, poor error handling, static initialization issues, etc. Anyway, Rust basically deals with it by giving the class designer the choice to supply factory f…

But you have exactly the same options in C++.

Really? What's the factory function invoked for a copy or a move?

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

#129

Post by layer8 »

jmyeet wrote: post #3

> Root cause > Traditional C++ exceptions have two main problems: > 1) the exceptions are allocated in dynamic memory because of inheritance and because of non-local constructs like std::current_exception. This prevents basic optimizations like transforming a throw into a goto, because other parts of the program should be able to see that dynamically allocated exception object. And it causes problems with throwing ex…

Regarding maintainability ("hard-to-follow"), I’ve become a big fan of Java’s checked exceptions (and also their causal chaining and adding of "suppressed" exceptions, which would be nice to have for C++ destructors). I effectively see them as a sum type together with the return type, just using different syntax. It’s an important reason why I stick to the language, because no other language has that kind of statically-typed exceptions.

As the article explains, the problems in C++ are more an ABI issue than a programming language issue (except for the by-reference vs. by-value semantics). You could implement exceptions internally by variant-like return values, for example, similar to how error passing is done in Rust, while still having it look like exceptions on the language level. It would be fun for future languages and runtimes to more easily be able to switch the underlying mechanism, or possibly to be able to use different implementation mechanisms for different parts of a program as needed.

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

#130

Post by zozbot234 »

jerf wrote: post #113
ModernMech wrote: post #51

Earlier quoted context omitted.

This is the great strength and weakness of C++. Increasingly the answer to C++'s rough edges is "We don't do things that way anymore. Everyone does X now", where X is the hot new thing. RAII is the best example I can think of, where some people insist that no one would ever use the "new" and "delete" keywords anymore. Except for all the C++ devs that do, and all the C++ code that exists that does and must be maintain…

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 it has settled into a lower-frequency churn rate lately for "best practices" than C++.

Rust is still adding a ton of new language features, especially around async, compile time code evaluation and the type system (const generics, GAT/HKT, existential types etc.). We'll very likely see further developments in more areas next, e.g. to match C++ developments in parallel and heterogenous compute (GPU's and the like), or to add forms of proof-carrying code, etc.

Post reply on HN