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

241–250 of 516 posts

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

#241

Post by pyjarrett »

pjmlp wrote: post #109
mjw1007 wrote: post #79

Earlier quoted context omitted.

One of the motivating examples for exceptions, at the time when they were beginning to appear in mainstream languages like Ada, was to allow people to write arithmetic expressions using familiar notation, while still having a place to put an error handler for the overflow case. Perhaps the lesson of the last forty years or so is that this convenience wasn't worth adding such a heavyweight feature to the language, but…

C++ is the only language where exceptions are such an ideology war. All the other ones that have born with exceptions don't have this issue, including Ada.

Ada exceptions are fundamentally different from C++ since they only carry type data with a possible message and no other user-defined data.

Old school C++ used to have additional try/catch blocks (and performance hit) inserted to ensure that functions match the given exception signature. Also, C++ usually focuses on performance, so all of the bookkeeping required for exceptions could historically be the last 3% or so difference between making your FPS rate or not.

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

#242

Post by passivate »

ModernMech wrote: post #51
nly wrote: post #6

Earlier quoted context omitted.

std::expected doesn't require language changes, it's a library type. If anything it shows how C++ is multi-paradigm

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…

>It leads to the current situation where you have C++ "the language" which is everything, and then C++ "the subset that everyone uses" where that subset constantly changes with time and development context.

But what exactly is wrong with that? I don't quite understand your argument here..

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

#243

Post by gumby »

JoeAltmaier wrote: post #213
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…

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 there's a design pattern where nearly everything is returned as an exception.

shudder The worst of cargo cults!

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

#244

Post by jgod »

xienze wrote: post #209
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…

> I run massive parallel data processing tasks on machines with 128 cores So, not to be rude here, but this may be a real-world scenario in your world, but not in everyone else’s. I get the sense the kind of stuff you’re working on would benefit from things like using assembly as well. But for desktop apps, games, compilers, other command line tools… who cares about the performance of throwing exceptions?

Games cares about it. But you're right that it's only very high-performance contexts.

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

#245

Post by ncmncm »

kfitch42 wrote: post #194
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…

Not only is this relevant to HPC environments, it also impacts the other end of the spectrum in the embedded space. When dealing with real-time requirements, you are much more concerned with the worst case performance as opposed to the average case or happy path performance. This article makes it very clear that exceptions complicate analysis of performance. The non-local nature of exceptions mean I can't analyze per…

Using local allocators where they offer some benefit certainly is idiomatic C++. Freeing all objects so allocated by simply reclaiming the blocks from a local allocator is also idiomatic C++.

Major subsystems that use no memory except what is passed in from above is also idiomatic C++.

C++ is a big tent. Things you do routinely in one part of a program, such as at startup, may be very different from what you do in a main loop, or in termination cleanup. Things my program does may be very different from what your program does.

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

#246

Post by talaketu »

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…

"exceptions are exceptional" means what?

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

#248

Post by CyberDildonics »

gpderetta wrote: post #236
CyberDildonics wrote: post #162

Earlier quoted context omitted.

That would turn communicating between threads into communicating between VMs, which is a disastrous change in itself.

It would. On the other hand multiprocessing with explicitly shared memory could be a fast (but potentially painful) workaround.

That could make sense for processes, which would also get around the exception unwind lock, but I don't know how that would work with every thread moved into a separate VM.

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

#249

Post by shrimpx »

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…

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, which is in many cases impossible to predict with accuracy. (E.g., even if only 1% of your inputs are malformed over all time, on some Thursday you may be hit with 80% bad inputs, making the performance drop across the service unacceptable.)

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

#250

Post by timClicks »

talaketu wrote: post #246
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…

"exceptions are exceptional" means what?

They're rare. Therefore their runtime costs have little impact on the overall running time. At least that's my understanding of the argument.
Post reply on HN