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

351–360 of 516 posts

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

#351

Post by Koshkin »

ncmncm wrote: post #346
Koshkin wrote: post #322

Earlier quoted context omitted.

But it's not. A lambda is merely syntactic sugar for an object (a functional) and as such it can carry a state (the term is 'closure' in this case); depending on what is being captured, its creation can even involve a heap allocation.

It is: "zero-overhead" is defined to mean you could not open-code it yourself any better. If you specify a capture-by-copy, you have specified a copy. If that copy involves an allocation, you have specified an allocation. There is exactly zero extra overhead: in the overwhelmingly most common uses, not even a call through a pointer. The good news is that the compiler knows all about lambdas, so can optimize the hell…

By "careful" I mean avoiding unnecessary use or the temptation of capturing "everything." All too often I see people get enamored with it or fall into the trap of following patterns popular in other, slower, languages.

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

#352

Post by Koshkin »

zozbot234 wrote: post #344
Koshkin wrote: post #322

Earlier quoted context omitted.

But it's not. A lambda is merely syntactic sugar for an object (a functional) and as such it can carry a state (the term is 'closure' in this case); depending on what is being captured, its creation can even involve a heap allocation.

Not sure I get your point - the exact same is true of a C function which is passed a void* ctx object, since those objects have to be allocated and their lifecycle has to be managed. It's still a zero overhead feature.

The (potential) overhead lies with 'ctx' of course. The lambda syntax makes it all too easy to forget about it.

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

#353

Post by Koshkin »

JAlexoid wrote: post #327
MauranKilom wrote: post #198

Earlier quoted context omitted.

Sure, but that in itself is also not an argument. The space of programming languages in general is moving forward and languages keep adding more (usually higher-level) features. C++ is mostly trying to keep up.

Adding features from literally every other language, just to create a mess - isn't really a selling point. Right now, to learn C++ in a generic way, you need to learn pretty much all of programming paradigms and all of their variations - which is not a thing I would consider a plus.

"Generic," maybe, but in practice many people learn C++ as one of, as it were, two languages - one for application code developers and the other, for those who build libraries and provide APIs.

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

#354

Post by kllrnohj »

fivea wrote: post #251
shrimpx wrote: post #249

Earlier quoted context omitted.

The problem is that in many practical situations you don’t know which situation is “exceptional”. If you write a jpeg-processing service, it’s intuitive to raise an exception on a malformed jpeg, but there’s no guarantee that only 1% of the jpegs users upload to the service are malformed. In other words, we treat exceptions as exceptions from our code expects , not what’s statistically unlikely in the input space, wh…

> If you write a jpeg-processing service, it’s intuitive to raise an exception on a malformed jpeg (..) Not really. Having to parse a malformed doc is not an exceptional situation: it's a basic use case, and one which is very close to the happy path.

And it's one for which exceptions are a perfect fit. Even if at the entry point of your "parseJpeg()" function you instead return a variant, internally propagating that error via exceptions is the "correct" design. Otherwise you're littering the code with branches, which makes the expected common path slower.

Which the paper covers, that's the std::expected section: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p254...

As a bonus not only is using exceptions for this faster, it's also less error prone. There's much less risk of any intermediate function or helper abstraction failing to propagate an error code properly.

Well, it would be if exceptions weren't avoided like the plague in C++ because they have a, well, bad implementation, which can't be meaningfully fixed without ABI breakges (as the paper covers)

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

#355

Post by Koshkin »

throwuxiytayq wrote: post #339
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.

But it's not reasonable, sensible or performant. Thankfully, I've never seen anyone abuse exceptions like that in C# or any other language, is it really a thing in C++?

Fortunately, it is not. As this discussion shows, people more tend to avoid exceptions for various reasons (both good and bad) than to abuse them.

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

#356

Post by gumby »

catskul2 wrote: post #343
gumby wrote: post #243

Earlier quoted context omitted.

> But there's a design pattern where nearly everything is returned as an exception. shudder The worst of cargo cults!

Is "cargo cult" really what you mean here. It doesn't seem to fit.

Yes, the blind following of "patterns" because you think that is what makes for "good code" is a perfect example. Especially when fitting the predefined pattern bends your implementation otherwise out of shape.

A design pattern is a way of communication. If you turn it into a procrustean tool you don't even understand why they exist.

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

#357

Post by ncmncm »

astrange wrote: post #218
ncmncm wrote: post #192

Earlier quoted context omitted.

Using up scarce branch-prediction slots is a good way to make your program unoptimizable. Time wasted because you ran out will not show up anywhere localized on your profile. (Likewise blowing any other cache.)

Using up BTB slots is an interesting problem but in practice doesn't seem to be a big issue. If it was, ISAs would use things like hinted branches but instead they've been taking them away. Code size is more important but hot/cold splitting can help there. A problem with using exceptions instead is they defeat the return address prediction by unwinding the stack.

That hinted branches are not useful tells us nothing about the importance of branch predictor footprint. When hinting branches gives you a bigger L1 cache footprint, it has a high cost. Compilers nowadays use code motion to implement branch hinting, which does not burn L1 cache. (Maybe code motion is what you mean by "hot/cold splitting"?)

Anyway the hint we really need, no ISA has: "do not predict this branch". (We approximate that with constructs that generate a "cmov" instruction, which anyway is not going away.)

How does using exceptions defeat return address prediction? You are explicitly not returning, so any prediction would be wrong anyway. In the common case, you do return, and the predictor works fine.

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

#358

Post by zabzonk »

Koshkin wrote: post #345
zabzonk wrote: post #301

Earlier quoted context omitted.

And those languages were badly designed. Which is why we don't have "procedures" or "subroutines" in modern programming languages" - just functions.

Well that's unfortunate. I suspect the fault lies with C, the early versions of which did not have the 'void' keyword, and 'int' was assumed as the default return type - which also meant that when such "function" did not include a 'return' statement it "returned" whatever garbage was left in the register. Instead of adding the keyword 'void' (to be abused later as the empty arg list) they could have added 'proc' inst…

> Well that's unfortunate

How so?

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

#359

Post by gumby »

tokumei wrote: post #342
gumby wrote: post #191

I find this paper quite unconvincing. Exceptions are exceptional so in principle it doesn't matter (within reason) how long it takes to throw one as long as it costs nothing not to do so. So measuring the cost of repeated throws IMHO doesn't cast light on any useful case, and the approaches that add runtime cost for the path not taken, even Herb Sutter's, are not acceptable. His code transformation example is simply…

I much prefer using a Result type now, even in C++. Makes it easier to reason about the code in my opinion.

The article shows that this approach adds to runtime even in the non-erring case.

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

#360

Post by Koshkin »

zozbot234 wrote: post #195
JAlexoid wrote: post #142

Earlier quoted context omitted.

One of the reasons why I try to avoid C++ is that it's an unopinionated multi paradigm kitchen sink language. There are great uses and great features, but there are so many of them and everyone has their own opinions.... Even in this thread there's a clear subset of people who "adore" C++ exceptions

There's no such thing as an "unopinionated" kitchen sink language. Language features have all sorts of unforeseen interactions that must be handled somehow, and good high-level design is needed to ensure that the interactions are sensible.

C++ is definitely unopinionated. Its evolution follows the path dictated by necessity, not opinion.
Post reply on HN