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

481–490 of 516 posts

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

#481

Post by CyberRabbi »

jcelerier wrote: post #464
CyberRabbi wrote: post #442

Earlier quoted context omitted.

If you allow exceptions in your real-time audio loop then when an exception occurs the only useful thing to do would be to take down the entire process. Handling exceptions as a norm in your audio loop would be unacceptable because it could never be done in a way that would always meet the deadline. In that case, if you cannot usefully handle the exception, why have your exceptional situation cause an exception in th…

> If you allow exceptions in your real-time audio loop then when an exception occurs the only useful thing to do would be to take down the entire process. as a user of audio software, I would really prefer them to have the occasional glitch instead of crashing , potentially loosing work. Like, how it is even a discussion ?

Sure but that isn’t the issue. We’re discussing the architecture of an audio loop, e.g. handling exceptions as a norm in the codebase. If it is avoided then there is no large behavioral difference between calling abort() and throwing an exception.

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

#482

Post by gumby »

atq2119 wrote: post #409
gumby wrote: post #232

Earlier quoted context omitted.

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.

Since this is about immutable "side car" data structures used during unwinding: could this be achieved using a soft ABI transition as opposed to a hard, flag day ABI break? Basically, going forward the compiler would emit two versions of the unwinding tables by default: the legacy one and the one that allows fixing the thread contention issue. The unwinder is changed to use the efficient version by default with the a…

That might work. It would be yet another thing that would slow down compilation (link phase in this case) but not the worst.

Compilers would have to generate both forms forever (except for new architectures) but probably that wouldn’t be terrible.

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

#483

Post by gumby »

talaketu wrote: post #413
gumby wrote: post #392

Earlier quoted context omitted.

In this aphorism, “prove” has an archaic meaning: “ tests the rule”. The point is that handling the host unreachable is almost always semantically higher level than the code opening the connection. This the code opening doesn’t implement the policy of what to do when the situation occurs. In the case, say, of a hard-coded address then it’s possible the author of that piece of code does know how to handle a host unrea…

Yes, this is said, but the meaning of "prove" (which is related to "probe") has not really changed very much at all compared to "test" - a word which in this sense is a metonym from the fired pot used for assay of metal. The meaning in "mathematical proof" or "prove beyond reasonable doubt" or "prove your love" doesn't really diverge significantly from this so-called archaic meaning - a demonstration to show. On the…

> I don't follow the paper's argument that "current exception design is suboptimal for efficient implementation"…

The argument of the paper is really that exception handling shouldn’t use a global lock, a problem made worse by the proliferation of processor cores on modern chips.

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

#484

Post by kllrnohj »

ncmncm wrote: post #478
kllrnohj wrote: post #444

Earlier quoted context omitted.

> That's why I recommend return values. You'll never hit a perf problem with them. > Exceptions cannot be used in code hot paths (~thousands of iterations) when it's not a small perf problem anymore. You should read the paper in the link. Both of your claims here are exactly backward. The problem is "just" that exceptions don't scale across multiple threads due to internally using a global lock. They are otherwise mu…

Yes. The article author's mistake was actually throwing those exceptions too often. For arithmetic errors, NaN is usually the better choice.

It's an exploration in scaling, how could that possibly have been a "mistake"? The paper isn't advocating for throwing an exception instead of returning NaN in the specific case of calculating a square root. It's instead only exploring the overhead & scaling of various error handling types.

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

#485

Post by kllrnohj »

wvenable wrote: post #393
randyrand wrote: post #325

Earlier quoted context omitted.

On top of that, you never know the context in which your users will call your library. Are you encoding a single file on a local machine? Or 1000 files on some HPC 128-core machine? Do we really want to be in a world where all libraries need to be written with and without exceptions since we can't know the context they'll be used in?

Why is the error occurring in the first place? In my opinion, exceptions/errors should be rare. If it's a software problem, it should eventually be fixed. If it's an infrastructure problem, it should be fixed. It's not just something that should continue to happen without any mitigation what so ever over time.

Not all errors have "fixes". If I navigate to "https://news.ycombinator.com/nope" it returns an error to me. Is that a software problem or an infrastructure problem? And what's the fix? How do you "fix" a bad input to the system from an external actor?

So no, errors/exceptions are not rare depending on the context. So now do you use exceptions and accept that it doesn't scale across core counts? Or do you use return values and accept that it just makes all your code slower in all cases?

1% error rate sounds like a lot. But really how many HTTP errors do web servers return on average? Or other such systems? It's definitely more than 0%, and those services also scale nicely across multiple cores, so... Now we're just bikeshedding over the example numbers, not the core issue.

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

#486

Post by jcelerier »

CyberRabbi wrote: post #481
jcelerier wrote: post #464

Earlier quoted context omitted.

> If you allow exceptions in your real-time audio loop then when an exception occurs the only useful thing to do would be to take down the entire process. as a user of audio software, I would really prefer them to have the occasional glitch instead of crashing , potentially loosing work. Like, how it is even a discussion ?

Sure but that isn’t the issue. We’re discussing the architecture of an audio loop, e.g. handling exceptions as a norm in the codebase. If it is avoided then there is no large behavioral difference between calling abort() and throwing an exception.

... I hope I just don't understand. Say you have some audio node in your engine which at some point fails because of some error condition, for instance it tried to load a preset in an invalid format which was supposed to be sanitized beforehand, the preset tried to load a sample and the OS returned -ENOPERM, whatever.

Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick, which loads the preset, fails, and then the program continues normally at the next tick, just with the wrong preset for a node, rather than calling abort() which entirely kills the program and looses what the user was working on ?

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

#487

Post by randyrand »

kllrnohj wrote: post #444
randyrand wrote: post #399

Earlier quoted context omitted.

> Point performance is the worst way to decide about error handling. My point is exactly that. It's more important to have a single common way of doing error handling than it is to have a small perf improvement. That's why I recommend return values. You'll never hit a perf problem with them. Exceptions cannot be used in code hot paths (~thousands of iterations) when it's not a small perf problem anymore. Therefore, t…

> That's why I recommend return values. You'll never hit a perf problem with them. > Exceptions cannot be used in code hot paths (~thousands of iterations) when it's not a small perf problem anymore. You should read the paper in the link. Both of your claims here are exactly backward. The problem is "just" that exceptions don't scale across multiple threads due to internally using a global lock. They are otherwise mu…

Are you sure? Single threaded

  18-16ms (boost::LEAF) vs 19-23ms (exceptions)
A better comparison is found here:

https://lordsoftech.com/programming/error-codes-are-far-slow...

> TL;DR On modern 64-bit PC architectures, C++ exceptions only add unreachable code with destructor calls into functions and their effect on performance is below 1%, but such low values are difficult to measure. Handling rare errors with return values requires additional branching that slows down the program in realistic scenarios by about 5% and are also less convenient. If an exception is actually thrown, stack unwinding costs about 2 µs per stack frame.

5% cost to using error codes. In exchange for that 5% you don't fall off a performance cliff if you hit a bunch of errors unexpectedly, and can confidently use them in hot paths and on CPUs with multiple cores.

I'll take the lower perf complexity and greater perf robustness of error codes any day. Reliability and predictability is more important to me than a 5% perf cost.

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

#488

Post by CyberRabbi »

jcelerier wrote: post #486
CyberRabbi wrote: post #481

Earlier quoted context omitted.

Sure but that isn’t the issue. We’re discussing the architecture of an audio loop, e.g. handling exceptions as a norm in the codebase. If it is avoided then there is no large behavioral difference between calling abort() and throwing an exception.

... I hope I just don't understand. Say you have some audio node in your engine which at some point fails because of some error condition, for instance it tried to load a preset in an invalid format which was supposed to be sanitized beforehand, the preset tried to load a sample and the OS returned -ENOPERM, whatever. Surely you agree that it's better to have this throw an exception, and a big try.. catch around your…

> Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick

Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad.

Generally your Audio loop should encounter no errors at all (it should be a pure process) so what the OP is saying is that excepting/aborting is fine in that case because it would truly be exceptional. I can’t imagine what the exceptional situation would be but to the extent one exists, I agree with that. My only point is that throwing an exception when there is no handler is no better than calling abort(), obviating the need for enabling exceptions.

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

#489

Post by jcelerier »

CyberRabbi wrote: post #488
jcelerier wrote: post #486

Earlier quoted context omitted.

... I hope I just don't understand. Say you have some audio node in your engine which at some point fails because of some error condition, for instance it tried to load a preset in an invalid format which was supposed to be sanitized beforehand, the preset tried to load a sample and the OS returned -ENOPERM, whatever. Surely you agree that it's better to have this throw an exception, and a big try.. catch around your…

> Surely you agree that it's better to have this throw an exception, and a big try.. catch around your audio callback so that just this tick Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad. Generally your Audio loop should encounter no errors at all (it should be a pure process) so what the OP is saying is that excepting/aborting is fine i…

> Yes I do agree but my point is that if any exception is being thrown for the sake of being handled then your Audio code is bad.

thank god ! then we both agree.

> Generally your Audio loop should encounter no errors at all (it should be a pure process)

and audio handlers should never lock mutexes yet I have seen my fair share of them in the wild.

> My only point is that throwing an exception when there is no handler is no better than calling abort()

every thread or event loop should always have a catch-all handler at top level.

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

#490

Post by chlorion »

andi999 wrote: post #91
ModernMech wrote: post #51

Earlier quoted context omitted.

This is the great strength and weakness of C++. Increasingly the answer to C++'s rough edges is "We don't do things that way anymore. Everyone does X now", where X is the hot new thing. RAII is the best example I can think of, where some people insist that no one would ever use the "new" and "delete" keywords anymore. Except for all the C++ devs that do, and all the C++ code that exists that does and must be maintain…

How do you get memory without new nowadays?

As well as smart pointers as others have mentioned, standard library containers (other than smart pointers) are another way to handle dynamic allocations in certain situations. The vector container is probably the best example here, it alone provides massive safety and usability benefits over using new or malloc directly!
Post reply on HN