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

231–240 of 516 posts

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

#231

Post by cesaref »

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…

I've worked in low latency trading, and with large distributed back testing setups with hundreds of high core count machines, and not once felt the need to disable exceptions, or for that matter, felt the impact of them happening. A fair bit of noexcept stuff was useful to improve runtime performance, but that was about it.

I would suggest you need to address that 1% of failing tasks and determine what the issue is, as frankly, you are solving the wrong problem. If I might suggest a solution, it sounds like you are using threading when process farms might be a better solution.

(and if i'm way off the mark with my suggestion, apologies, i'm trying to help and have little information to work with).

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

#232

Post by gumby »

cryptonector wrote: post #220
gumby wrote: post #210

Earlier quoted context omitted.

> How exceptional exceptions really are depends on the code being run. Well yes, but EH is basically trying to be the best way to do a highly non-local goto with a dynamic target. If that part is your bottleneck than indeed you may have a more specialized requirement. I do on occasion build a homemade version of a standard library datatype because I have a specialized need and only need implement the subset our code…

I agree. I'm not sure breaking the ABI to fix the unwinder serialization issue should be a show-stopper, considering that there still isn't a C++ ABI.

Th problem is that the corpus of deployed libraries is a de facto ABI. Even with dylib versioning, catching the case of API version is hard.

I think it could be done by changing the mangling algorithm (basically: compile fails if new-ABI versions are not available) but I haven't thought enough about it to remove the words "I think" from the beginning of the sentence.

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

#233

Post by taeric »

nybble41 wrote: post #214
mcguire wrote: post #177

Earlier quoted context omitted.

" 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.

> By people who do not want to believe that errors are part of a system's API… The point was that you should be returning errors, not throwing them. Runtime exceptions (null reference, division by zero, out of memory, etc.) ought to indicate a fatal error in the (sub)program or runtime environment. You can trap these, and report them, but it's usually a mistake to try to case-match on them. Unlike errors, which are p…

I disagree with this. But, I'm also a fan of the condition system in Common Lisp.

That is, if the problem is likely one that needs operator/user intervention, the non local semantics of exceptions makes a ton of sense. Indeed, it is useful to have a central handler of "things went wrong" in ways that is cumbersome if every place is responsible for that.

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

#234

Post by JoeAltmaier »

gumby wrote: post #227
JoeAltmaier wrote: post #213

Earlier quoted context omitted.

But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. I deplore that - its side-effects writ large. But those that use it, find it reasonable and sensible. It's become hard to distinguish right and wrong when it comes to CPU optimization. Different versions of the 'same' CPU can have wildly different sweet spots.

> It's become hard to distinguish right and wrong when it comes to CPU optimization. Different versions of the 'same' CPU can have wildly different sweet spots. Indeed, though I am shocked when people post benchmarks in which they are obviously unaware of this issue. It's why compilers have all those architecture switches. If I understand your comment correctly: in the case of the posted paper, the compiler optimizat…

You're right, the issue is convoluted and nuanced. There are architecture issues, cache sizes and layers to consider, cost of misses and writes, alignment and bus sizes.

Oh for the good ol days when register size was all you had to think about!

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

#235

Post by lanstin »

mcguire wrote: post #177
dtech wrote: post #170

Earlier quoted context omitted.

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.

The compiler makes them part of the API. And what a lot of people do is just throw in a bunch of blanket catches with empty code. Although some of this is server vs. desktop software - the article was about complex GUI apps, not long running servers. Tho I personally think long-running servers shouldn't use exceptions. Each call to something out of the running code stack frame should explicitly decide what to do on failure or "didn't hear back." That's how your server gets to be bullet proof (and by bullet proof, I don't mean "auto-restarts on unhandled exception.")

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

#236

Post by gpderetta »

CyberDildonics wrote: post #162
tjungblut wrote: post #153

Earlier quoted context omitted.

If you run into contention issues have you tried scaling horizontally? Running on 128 single core VMs should mitigate what you see.

That would turn communicating between threads into communicating between VMs, which is a disastrous change in itself.

It would. On the other hand multiprocessing with explicitly shared memory could be a fast (but potentially painful) workaround.

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

#237

Post by lanstin »

PaulDavisThe1st wrote: post #193
tneumann wrote: post #148

Earlier quoted context omitted.

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…

True but also libraries and people thinking differently. Numeric is not real-time, tho it has many common characteristics.

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

#238

Post by adrian17 »

cryptonector wrote: post #208
adrian17 wrote: post #196

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.

The problem is that if you have exception-happy code, then it becomes a scalability limiter for threading.

Yes, if A: you have code that's expected to "fail" relatively many times, and B: this code is also multithreaded. A lot of code doesn't match one or both of these conditions while still being perf-sensitive.

Further, as you can see in other comments, it's not an uncommon belief that exceptions simply shouldn't be used for A (and thus it's reasonable that they aren't optimized for something they aren't supposed to be used for).

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

#239

Post by ncmncm »

jandrese wrote: post #187
mcguire wrote: post #171

Earlier quoted context omitted.

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

I think he's arguing that C++ exceptions are unsuitable for parallel data processing, at least in cases where exceptions are regularly thrown.

There is the red flag: "regularly thrown". "Regularly" is opposite to "exceptionally".

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

#240

Post by lanstin »

mwcampbell wrote: post #134
kccqzy wrote: post #96

Earlier quoted context omitted.

> 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. This is a pro not a con. It now shows clearly that all these function calls are now failable. Of course at higher levels you may have additional assumptions that you know won't make the low-level functions fail, and you are welcome not to change e…

> Panics do not need to be caught and handled. You can (and should) transform panics into abort. I think this strong stance needs some justification, especially since it's not the default in Rust.

It is in Go Lang which shares error handling philosophy with GP.
Post reply on HN