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

151–160 of 516 posts

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

#151

Post by jcelerier »

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 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 resource limit exhausted.. things like that). As much as massive parallel data processing tasks matter, I'd really prefer my language to not side-step writing end-user apps for something that happens at $bigcompany or $bigresearchlab.

here's the list of binaries that link against libstdc++.so.6 in my /usr/bin: https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 - don't forget those please :)

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

#152

Post by ncmncm »

_0w8t wrote: post #42
rossmohax wrote: post #20

If not exception, then how to fail constructor?

Signal failure via an out parameter reference. For destructors store the reference in the object and call an error method on errors.

That is the worst of all possible choices.

Just throw.

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

#153

Post by tjungblut »

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 run into contention issues have you tried scaling horizontally? Running on 128 single core VMs should mitigate what you see.

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

#154

Post by ncmncm »

addaon wrote: post #77
_b wrote: post #67

Earlier quoted context omitted.

Don't write constructors that can fail unless it is failure that would be appropriate to crash for. That works out a lot better than it might naively sound. It is hard for people to reason about the possibility of constructors/destructors failing, so actually rather nice to just forbid it.

And for those super-rare cases where it's appropriate to crash / fail hard in a constructor but you still have requirements about reporting or even recovery... setjmp/longjmp still exist.

You have always had the choice available to do something overwhelmingly worse than throwing. That is not a reason to do it.

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

#156

Post by brundolf »

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 curious whether Rust's Result gets special optimization treatment from the compiler that std::expected doesn't

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

#157

Post by CyberDildonics »

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…

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?

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

#158

Post by JAlexoid »

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.

Errors and exceptions aren't necessarily low in all cases.

And in any case this is about how these exceptions impact parallel processing - and the impact is not negligible.

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

#159

Post by wvenable »

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…

> and 1% of your tasks fail

That's a lot of failures. I'd question whether or not you should be using exceptions for something that happens 1% of the time all the time.

Admittedly you might not have any choice in the matter if it's a dependency that is failing.

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

#160

Post by Koshkin »

zabzonk wrote: post #26

> As illustrational example consider this small code fragment: Consider this crap small code fragment. Any function that returns void is almost certainly wrong.

You are right. That's why in good old languages they were called 'procedures.'
Post reply on HN