Current hardware trends make C++ exceptions harder to justify • Hacker News Board

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

#161

Post by im3w1l » Tue, Feb 22, 2022, 7:47 PM UTC

masklinn wrote: post #121

HelloNurse wrote: post #108

Earlier quoted context omitted.

If the program fails too often or too unfairly, why should you blame how such failures are handled? The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception", even if actually thrown exceptions were fast.

> If the program fails too often or too unfairly, why should you blame how such failures are handled? Because the discussion is about methods of reporting and handling failure? > The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception" That makes no sense whatsoever, and doesn't address the question. And even if a ctor fails…

You could use an output pointer parameter. You could construct an object which self-reports as invalid. You could take an error handler callback. You could use a global variable.

Or I think my preference would be a private constructor, and a friend-function that returns value-or-error.

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

#162

Post by CyberDildonics » Tue, Feb 22, 2022, 7:47 PM UTC

tjungblut wrote: post #153

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…

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.

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

#163

Post by zozbot234 » Tue, Feb 22, 2022, 7:47 PM UTC

throw10920 wrote: post #140

john567 wrote: post #27

Why do we need to have ambient control flow? This is what exception handling is, it's a hidden control flow. I don't use them. I just create an error type and pass that around. The only legitimate exception I will accept is when you access invalid memory. That's a special case and depending on the environment something extraordinary must happen. But exceptions and exception handling just creates annoying code. It doe…

> Why do we need to have ambient control flow? Because, properly-used, it saves you a lot of effort. Returning an error type unwinds the stack. If I have a low-level computation that has a number of error cases, and I want the high-level code to intelligently handle some of those error cases and continue processing, that's not doable using return values. Error codes bind the decision of which error-recovery strategy…

> What if you have a long-running operation? If you return an error value when that operation happens, but it turns out the nature of the operation allows you to ignore that error and continue, you'll have to re-start the entire computation.

This is just as much of a problem with exceptions. "Fix the error and continue" needs some equivalent to resumable conditions, which are generally implemented at the "low level" using coroutines. My understanding is that async-await as a language feature might be able to express these with relative ease, but exceptions alone clearly do not suffice.

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

#164

Post by tneumann » Tue, Feb 22, 2022, 7:47 PM UTC

fwsgonzo wrote: post #37

yakkityyak wrote: post #19

Earlier quoted context omitted.

I'm not convinced a recursive implementation of `fib` is a reasonable example to draw such a conclusion.

It really isn't. People need to stop making trivial benchmarks and draw ... silly ... conclusions. http://www.eecs.northwestern.edu/~robby/courses/322-2013-spr... It is a fact that C++ exceptions are largely low overhead, and that you also don't have to use them. In fact, C++ can make everyone happy, because you can choose which parts you like. Personally, knowing how exceptions are implemented and having implemented…

Of course the fib example is extreme. But some code bases do a lot of calls, and people care about calling overhead. I think a moderate calling overhead like, e.g., with Herbecptions is acceptable, because usually people doing something useful in a function that will mask the calling overhead. But other approaches are really to expensive to justify, they violate the zero-overhead promise of C++.

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

#165

Post by downut » Tue, Feb 22, 2022, 7:49 PM UTC

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.

In 30 years of c++ I've never seen error checking + throw in a tight numeric intensive loop like this. Sure, somebody could do it. I'd have a chat with a coworker who wrote something like that.

I only use exceptions for cleanly unwinding the stack when an unrecoverable error occurs. I design and implement my code so that is rare.

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

#166

Post by AnimalMuppet » Tue, Feb 22, 2022, 7:50 PM UTC

worik wrote: post #44

Begs the question: Why C++? Legacy projects (I am not being pejorative, they are important) which must be maintained aside, should not C++ be deprecated? We have many new languages, we always had C. What does C++ give us in 2022 that makes up for the enormous cognitive load of understanding and keeping up with it.

> What does C++ give us in 2022 that makes up for the enormous cognitive load of understanding and keeping up with it.

If I were starting a greenfield project today, I might choose C++ for it, depending on what it was. (Pick the best tool for the job, and all that.) But if I picked C++, I would not use the full enormity of the entire C++ language specification. I would use the parts that helped with the program I was trying to write, and explicitly not use the rest of it.

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

#167

Post by ncmncm » Tue, Feb 22, 2022, 7:50 PM UTC

freedomben wrote: post #64

worik wrote: post #44

Begs the question: Why C++? Legacy projects (I am not being pejorative, they are important) which must be maintained aside, should not C++ be deprecated? We have many new languages, we always had C. What does C++ give us in 2022 that makes up for the enormous cognitive load of understanding and keeping up with it.

C++ is still a wonderfully performant language, and there are still domains where it is clearly a leader (networking, games/graphics, etc). Rust is slowly displacing it but there's still a lot of road left. The maturity, stability, prior art are also worth something. The pitfalls are really not that big and dangerous, although to someone who doesn't do C++ I can see why it has that perception. Additionally, if you ar…

More people start using C++ professionally in any given week that the sum total paid to code Rust.

Rust is not "displacing" C++ anywhere beyond the HN echo chamber.

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

#168

Post by wvenable » Tue, Feb 22, 2022, 7:50 PM UTC

zozbot234 wrote: post #86

edflsafoiewq wrote: post #72

Earlier quoted context omitted.

My problems with Result/expected/etc 1. They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. 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. 3. Since the caller must be aware of them, generic code generally has to be Result-aware too. 4. The…

> They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. This is not "noise" but needed information. A function that can error out should not have the same signature as one that will never return an error. Similarly, call-site special syntax (like '?' in Rust) helps address the concerns raised by hidden control flow. > Since the caller must be aware of them, gener…

> A function that can error out should not have the same signature as one that will never return an error.

Functions that never fail are pretty rare compared to ones that do. It's easier to just assume that all functions can fail. Mentally it's a much simpler model.

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

#169

Post by henrydark » Tue, Feb 22, 2022, 7:51 PM UTC

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.

96 virtual cores is a popular choice on AWS, being cost effective in some industry scenarios. I'm certain the analysis of the piece applies

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

#170

Post by dtech » Tue, Feb 22, 2022, 7:52 PM UTC

layer8 wrote: post #129

jmyeet wrote: post #3

> Root cause > Traditional C++ exceptions have two main problems: > 1) the exceptions are allocated in dynamic memory because of inheritance and because of non-local constructs like std::current_exception. This prevents basic optimizations like transforming a throw into a goto, because other parts of the program should be able to see that dynamically allocated exception object. And it causes problems with throwing ex…

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+ lambda API's.

Especially when used as an error ADT they're awful because they mix everything from "you have to handle this 90% of the time" to "the universe physics just changed, sorry" into one construct. Much better to use something like Vavr's Try and explicitly propagate the error as a value.

[1] https://www.artima.com/articles/the-trouble-with-checked-exc...