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

191–200 of 516 posts

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

#191

Post by gumby »

I find this paper quite unconvincing.

Exceptions are exceptional so in principle it doesn't matter (within reason) how long it takes to throw one as long as it costs nothing not to do so. So measuring the cost of repeated throws IMHO doesn't cast light on any useful case, and the approaches that add runtime cost for the path not taken, even Herb Sutter's, are not acceptable.

His code transformation example is simply the compiler behaving properly, unless it can't make that transformation even when foo() is declared noexcept.

The high core count is a real issue and a legitimate reason for an ABI break. Exceptions are the kind of below the surface plumbing that can't reasonably be implemented in regular code.

And in that regard the paper does make a good suggestion, though it then dismisses it! The tree approach described in section 3.4 seems like the right kind of fix.

Ultimately there's a spectrum of branching (`return` -> `break` -> `goto` -> `throw`) all of which need consideration in light of multicore deployment.

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

#192

Post by ncmncm »

masklinn wrote: post #57
fbkr wrote: post #7

Earlier quoted context omitted.

I've been using `expected`, i.e. value-or-error type, for a while in C++ and it works just fine, but the article shows it has some noticeable overhead for the `fib` workload for instance. Not sure if the Rust implementation has a different design to make it perform better though.

> Not sure if the Rust implementation has a different design to make it perform better though. Prolly not, I expect the issue comes from the increase in branches since a value-based error reporting has to branch on every function return. Even if the branch is predictible, it’s not free. And fib() would be a worst-case scenario as it does very little per-call, the constant per-call overhead would be rather major.

Using up scarce branch-prediction slots is a good way to make your program unoptimizable. Time wasted because you ran out will not show up anywhere localized on your profile. (Likewise blowing any other cache.)

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

#193

Post by PaulDavisThe1st »

tneumann wrote: post #148
ziml77 wrote: post #34

I find this analysis strange. Yes, C++ does need ergonomic ways to return an error without dynamic allocation (Rust's magic of ? combined with the From/Into traits is nice), but 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. It's not really an exceptional circumstance at that point.

That argument is only true in single threaded applications, at least given today's exception implementations. The more threads you have, the more problematic exceptions become. On the large machine you start to see performance problems with 0.1% failure rate, which is not that much. An core counts continue to rise.

Again, most experienced C++ programmers would say that even a 0.1% "normal" failure rate indicates a situation that should not be handled by exceptions. You seem to be describing a style of programming where there's a bunch of work to be done, most efforts to do the work will succeed, a few will predictably (albeit randomly, perhaps) fail. While I would concede that you might conclude that exceptions are the perfect tool to use to deal with the failures...

1) you're describing a fairly unusual application behavior 2) it's only because of the performance goals that the speed of exceptions matters

I'm the lead dev of a cross-platform DAW where our "inner loop" is real-time constrained by hardware. We use exceptions freely (in a multicore, multithreaded context) with no performance issues, because if they ever happen, things must stop.

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

#194

Post by kfitch42 »

tneumann wrote: post #135
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 am the the original author, and trust me, I am describing a real world problem. I run massive parallel data processing tasks on machines with 128 cores, and unfortunately some of them produce errors deep within the processing pipeline. From a programming perspective exceptions would be ideal for that scenario, but they cause severe performance problems. Just think about this: If you have a 100 cores, and 1% of your…

Not only is this relevant to HPC environments, it also impacts the other end of the spectrum in the embedded space. When dealing with real-time requirements, you are much more concerned with the worst case performance as opposed to the average case or happy path performance.

This article makes it very clear that exceptions complicate analysis of performance. The non-local nature of exceptions mean I can't analyze performance in isolation. E.g. I can test that thread 1 always meets its deadlines (even with exceptions being thrown), then I can test that thread 2 always meets its deadlines.... but if thread 1 and thread 2 happen to throw exceptions at nearly the some time I might miss both deadlines. Who knows, maybe this means a thruster fires too long and that insertion burn fails ... and Mars has a new crater instead of a lander.

And, once you throw -fno-exceptions you are no longer using standard C++, which the standard library assumes. So, using anything that would throw exceptions on memory allocation failures is a no-go. You can work around this with extensive use of allocators (that reference enough static memory to avoid any possible out-of-memory situation)... but this is not looking like idiomatic C++ anymore, and most off-the-shelf libraries are unusable.

A completely local exceptions implementation (e.g. Herbceptions) would solve this.

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

#195

Post by zozbot234 »

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

There's no such thing as an "unopinionated" kitchen sink language. Language features have all sorts of unforeseen interactions that must be handled somehow, and good high-level design is needed to ensure that the interactions are sensible.

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

#196

Post by adrian17 »

This paper confirmed what I suspected for some time: exceptions are still the only basically-zero-overhead solution available, which ironically completely justifies their existence in usage patterns where exceptions are actually exceptional. There are times when writing/profiling Rust when I wish I had access to exceptions instead of `Result` propagation.

I do agree with the mentioned design issues though.

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

#197

Post by gpderetta »

masklinn wrote: post #128
gpderetta wrote: post #101

Earlier quoted context omitted.

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

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

Whatever you want it to be. By default of the compiler will generate calls to move and copy constructors.

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

#198

Post by MauranKilom »

JAlexoid wrote: post #146
Koshkin wrote: post #125

Earlier quoted context omitted.

> C++ just can't seem to stabilize It's not like C++ is oscillating. It continues to improve, which is a good thing.

Adding more and more features isn't necessarily an "improvement".

Sure, but that in itself is also not an argument. The space of programming languages in general is moving forward and languages keep adding more (usually higher-level) features. C++ is mostly trying to keep up.

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

#199

Post by [deleted] »

tneumann wrote: post #135
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 am the the original author, and trust me, I am describing a real world problem. I run massive parallel data processing tasks on machines with 128 cores, and unfortunately some of them produce errors deep within the processing pipeline. From a programming perspective exceptions would be ideal for that scenario, but they cause severe performance problems. Just think about this: If you have a 100 cores, and 1% of your…

[deleted]

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

#200

Post by TillE »

ncmncm wrote: post #133
erwincoumans wrote: post #111

Earlier quoted context omitted.

C is fine too. I pick a C++ subset that is closer to C than to full modern C++17. Full control over memory access, hardware access and execution. I haven't learned enough Rust yet, that could be fine too, but Rust lacks still many libraries in Robotics and Game development. What else do you suggest?

In other words, you pick exclusively the worst features of C++, and ignore all the actually useful, helpful features that enable you to write better code. If you just want C, use C.

"Modern C++ bad" is such a weird HN meme, fortunately it's not an opinion I see a lot elsewhere. Old C++ was awful, the new stuff makes it actually usable.

Personally I like how even in embedded code where you don't want to include the standard library, you can still efficiently use language constructs like constexpr, lambdas, etc.

Post reply on HN