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

181–190 of 516 posts

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

#181

Post by nicoburns »

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 feel like the main problem with exceptions isn't the performance, it's the non-local control flow and the fact that it makes enumerating all possible failure modes almost impossible. IMO the only way that exceptions could be justified (other than being the status quo) is if they were much faster than Result/Maybe types. Performance parity doesn't make them worthwhile!

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

#182

Post by jrockway »

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.

Those Threadrippers have two vCPUs per core, so you can definitely have 128 things that appear to proceed in parallel.

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

#183

Post by CJefferson »

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.

Counter-conterpoint: I've worked on two applications C++ which we had to "de-exception", as exception handling was taking >25% of the time when we profiled.

You could argue we were using "too many exceptions", but to me it's the obvious way to unwind in C++.. except it's not fast enough, so we had to switch to a proto-Rust (this was before Rust) style system.

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

#184

Post by mikepurvis »

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

Sure, but the point is that providing factories requires extra work and consideration, so a lot of C++ classes instead lean on the default option of a constructor. Rust's removal of that forces the class designer to choose.

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

#185

Post by PaulDavisThe1st »

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?

for ones that throw an exception for 1% of a unit computation, perhaps yes.

But as has been noted, that's a lot of failures and exceptions may not be the appropriate mechanism to deal with this type of failure.

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

#186

Post by cryptonector »

(Exceptions are bad, full stop. It should all have been monadic all along, with Maybe/Either/Result.)

That said, exceptions should have been allocated on the stack, and catch handlers should have been closures that get called with the exception object. I guess this can't be implemented now.

As for multi-threading unwinding, the issue there is that unwinding tables are part of the shared objects whence the associated object code comes, and it often has to be possible to unload loaded shared objects, so now what? The situation shouldn't be bleak though: a shared object should never be unloaded while there are threads executing its code, so it should be possible to arrange a slow unload-time operation to update the the process-wide unwinding tables -- think of user-land RCU if you like.

The exception handling code should not have to synchronize around unwinding, except that when unwinding completes it might have to notice that there's a pending unload, so wake the thread that is waiting for unwinding. Or maybe not even, because maybe unloading could do something truly breathtaking like check that no thread's stack includes return addresses from the object to be unloaded, and then unwinders would never need to step into the unwinding tables from that object.

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

#187

Post by jandrese »

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?

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

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

#188

Post by edflsafoiewq »

masklinn wrote: post #114
rr808 wrote: post #62

Earlier quoted context omitted.

Best to create object then initialize it in a separate method.

Because that meshes so well with copy and move ctors, const and reference members, or inheritance.

It meshes well with move ctors at least, since objects need a "dead state" they can be put into when moved from.

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

#189

Post by CJefferson »

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.

Why am I "not supposed to use exceptions"? I don't understand why exception should be used when errors occur occasionally, or when they occur 50,000/sec. They are a control flow method for when errors occur.

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

#190

Post by tneumann »

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.

A dual socket EPYC costs about 15K. You can rent some online for 400$ a month. This gives you 128 cores for a relatively low price.
Post reply on HN