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

171–180 of 516 posts

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

#171

Post by mcguire »

jcelerier wrote: post #151
tneumann wrote: post #135

Earlier quoted context omitted.

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…

> I am the the original author, and trust me, I am describing a real world problem. for a more-or-less niche part of "real world". The overwhelming majority of desktop GUI apps rely on some C++ system - Qt, gtkmm, Wx, Blink, Gecko, FLTK, etc etc... and it is not an issue for those, for what exceptions are commonly used for (a write failing because the user disconnected the USB drive while it was copying, a system res…

Are you arguing that C++ is unsuitable for massive parallel data processing tasks?

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

#172

Post by ncmncm »

forrestthewoods wrote: post #10

> Nevertheless the overhead is so high that std::expected is not a good general purpose replacement for traditional exceptions. This is basically the path Rust has chosen. I’m curious if it’s _actually_ too slow for C++. I feel like the answer must be no.

It is always easy to find places where performance doesn't matter, and even Python is fast enough, including startup code in programs where performance otherwise does matter.

You cannot draw useful inferences from those cases.

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

#173

Post by aphexairlines »

mikepurvis wrote: post #87
chippiewill wrote: post #80

Earlier quoted context omitted.

You could potentially argue that, but certainly Rust doesn't encounter this issue despite being const by default because they simply don't have constructors in the first place.

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…

It's also easy to provide a default factory: https://doc.rust-lang.org/std/default/trait.Default.html

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

#174

Post by mcguire »

netr0ute wrote: post #137
henrydark wrote: post #93

Earlier quoted context omitted.

As per the piece, open 128 documents on a 128 core machine, and you'll see the difference.

How many people actually use a 128 core machine though? The absolute biggest AMD Threadripper you can get only has 64.

No one needs more than 64 cores?

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

#175

Post by tneumann »

CyberDildonics wrote: post #157
tneumann wrote: post #135

Earlier quoted context omitted.

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…

All of this hinges around the global lock, although I'm not sure what you mean exactly. Are you talking about memory allocation, a lock that exception handling takes or something else?

The main problem is the unwinding lock. Memory allocation is a bit unfortunate, too, but much less so.

Note that I am trying to fix the unwinding problem, I have submitted a patch to libunwind to eliminate the contention during unwinding:

https://reviews.llvm.org/D120243

It require application support, unfortunately, as there is currently no way that libunwind can figure out if a shared library has been added or removed. But if you are willing to indicate that from within the application the performance problem is mostly fixed. The memory allocation issue remains, but I can live with that. I cannot live with single threaded unwinding.

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

#176

Post by xrikcus »

masklinn wrote: post #52
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.

> 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…

Adding to that once exceptions start being thrown, that ratio changes because the cost is so high. It's not hard for a service to reach a failure rate just high enough that it overwhelms the system.

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

#177

Post by mcguire »

dtech wrote: post #170
layer8 wrote: post #129

Earlier quoted context omitted.

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 statical…

Java's checked exceptions are generally regarded as a mistake. There's a reason no other languages has them, and newer JVM languages (Groovy, Clojure, Scala, Kotlin) treat all exceptions as runtime. Anders Hejlsberg (creator of Delphi, C# and Typescript) also has an excellent article on their problems [1]. In modern Java I see nearly only runtime exceptions used, especially because that's necessary for most Java 8+ l…

"Java's checked exceptions are generally regarded as a mistake."

By people who do not want to believe that errors are part of a system's API and prefer to just write the happy path and let any exception kill the process. And who don't mind getting called at 2:00 am because a dependency buried deep in a subsystem threw an exception that you'd never heard of before.

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

#178

Post by ncmncm »

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…

If you are seeing 1% of operations failing, I can guarantee you are Doing It Wrong.

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

#179

Post by nybble41 »

netr0ute wrote: post #137
henrydark wrote: post #93

Earlier quoted context omitted.

As per the piece, open 128 documents on a 128 core machine, and you'll see the difference.

How many people actually use a 128 core machine though? The absolute biggest AMD Threadripper you can get only has 64.

> The absolute biggest AMD Threadripper you can get only has 64.

You can get a machine with dual 64-core AMD EPYC 7662 CPUs[0] for a total of 128 cores. It will cost you almost $20k, though—for the most basic configuration.

[0] https://bizon-tech.com/bizon-x6000.html#959:8714;960:4858;96...

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

#180

Post by garbagecoder »

mcguire wrote: post #171
jcelerier wrote: post #151

Earlier quoted context omitted.

> I am the the original author, and trust me, I am describing a real world problem. for a more-or-less niche part of "real world". The overwhelming majority of desktop GUI apps rely on some C++ system - Qt, gtkmm, Wx, Blink, Gecko, FLTK, etc etc... and it is not an issue for those, for what exceptions are commonly used for (a write failing because the user disconnected the USB drive while it was copying, a system res…

Are you arguing that C++ is unsuitable for massive parallel data processing tasks?

No, he's arguing that he'd prefer it not be if that means breaking support for end user apps which is what the OP is arguing for.
Post reply on HN