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

461–470 of 516 posts

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

#461

Post by ATsch »

josephg wrote: post #370
ATsch wrote: post #321

Earlier quoted context omitted.

I think, given a language that supports elegantly catching exceptions, it is inevitable that things like that will be written. And why not? The language makes them nice to write, which signals to users that it is something you should be using a lot. I think the approach Go, Rust and others take there is the right way to go. By making panics annoying or even impossible to recover from in some cases, they ensure that t…

> it is inevitable that things like that will be written. And why not? We can't just blame the programming language for programmers not understanding how computers work. I think as computers have gotten faster, and languages higher level, we've stopped talking about computers as mechanical devices. And this is a really important perspective to have. Can you answer these questions about your program? - How big is your…

I'm not sure what you're arguing with here. The need to understand what you're doing is not at odds with designing our tools to make it easy to do the right thing. Quite the opposite, knowing what we are doing helps us write good tools and good tools help us know what we are doing.

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

#462

Post by pavon »

patrick451 wrote: post #379
pavon wrote: post #287

Earlier quoted context omitted.

In C++ the convention is that exceptions shouldn't be used for things you expect to happen in the normal execution of the program, in a way that would harm performance. For example, it is better to explicitly check if an item is in a map than to rely on exception handling to branch to the case where the item doesn't exist. Generating an exception for FileNotFound would be fine for a single file selected by the user i…

I'm not really a fan of this pattern in python. As far as I can tell, it's all done in the name of duck typing: if the returned object appears to have the right property, that's good enough. But the problem comes when take that object and pass it on to some other function. It may have appeared like a duck to you, but 10 functions later, it's slightly off and you get a difficult to understand TypeError or AttributeErr…

In C++ I would consider the best option in those cases would be for the function that performs the operation to return an error rather than throw an exception. That way you avoid the race condition, but also don't have to worry about the overhead of calling it in a tight loop.

If the library you are using does throw exceptions, then I would probably start with just using exception handling. Then if I notice poor performance, add an initial check, purely as an optimization, while keeping the exception handling to deal with race condition.

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

#463

Post by ModernMech »

ncmncm wrote: post #443
bogeholm wrote: post #440

Earlier quoted context omitted.

I read OP’s complaint as “it is no coherent”

That is code for "it is evolving and I cannot be bothered to keep up". All languages that are actually useful evolve. They get features that other people need, and you don't, just yet. Some of those features do turn out not to be perfect, because they are made by humans. Comparing an old language to a new language, the new language will have many fewer of those both because it leaves many old things behind, and becau…

> "it is evolving and I cannot be bothered to keep up"

No, I actually teach C++ and have been keeping up with it for decades. It was the second language I learned in 1994 and I still code in it professionally today.

> Give it time, and it will accumulate "incoherence" of its own; the faster it evolves, the faster that happens.

Like I pointed out with Matlab, it’s a much older language compared to c++ yet is mostly coherent, far more than c++. This has less to do about C++’s age and the March of time or the human condition. Otherwise more old languages would be as incoherent as c++ yet that’s not the case.

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

#464

Post by jcelerier »

CyberRabbi wrote: post #442
cesaref wrote: post #427

Earlier quoted context omitted.

Well i'm now working in a hard realtime domain (audio, noone dies when it goes wrong, but it's still hard realtime) and i've still got exceptions turned on. But no exceptions are thrown during runtime, they're there for exceptions. Yes, there's overhead in places, but we noexcept some code paths to reduce that overhead in some very hot code paths.

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 ?

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

#465

Post by jcelerier »

CJefferson wrote: post #189
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.

> . They are a control flow method for when errors occur.

no, not any errors, exceptional errors. Input data coming from "outside" being invalid is not exceptional. The filesystem suddenly becoming inaccessible during a copying or caching operation, the OS not being able to join a thread, your logging backend becoming unable to log because the disk is full, or a regular expression being incorrect are what comes to mind when I think of exceptional situations (unless your program allows users to input regexps). If your program runs on a normal computer in normal conditions, no exceptions should ever be thrown.

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

#466

Post by throw10920 »

zozbot234 wrote: post #163
throw10920 wrote: post #140

Earlier quoted context omitted.

> 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"…

I didn't actually say the word "exceptions" anywhere in my comment. That's because I agree that exceptions are not enough - but the solution that is enough, namely conditions and restarts, also requires "ambient control flow" to use the language of the parent. I was arguing for that and against return values, not for exceptions.

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

#467

Post by jcelerier »

michaelnik wrote: post #340
CJefferson wrote: post #189

Earlier quoted context omitted.

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.

I'd add a (major) inconvenience is problem investigation, often exceptions point you to root cause and all you need it to break on the first exception (think after running big codebase, for an 1h just to get where problem is), but if they are thrown willy-nilly this debugging strategy is MUCH less convenient...

yep, it's great to just `catch throw` in gdb, launch tests, and things will stop exactly when the error happens

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

#468

Post by cma »

cesaref wrote: post #231
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've worked in low latency trading, and with large distributed back testing setups with hundreds of high core count machines, and not once felt the need to disable exceptions, or for that matter, felt the impact of them happening. A fair bit of noexcept stuff was useful to improve runtime performance, but that was about it. I would suggest you need to address that 1% of failing tasks and determine what the issue is,…

Even reducing it to .1% we'll still have 1000 cores or at least threads before too long. GPUs already have thousands. Prosumer CPUs already have 128 threads. Epyc supports SMT, and will be 512 threads on dual socket Bergamo in 2023 I think on the roadmap. There is an intermediate at 384 threads dual socket Genoa in 2022.

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

#469

Post by ncmncm »

ModernMech wrote: post #448
ncmncm wrote: post #429

Earlier quoted context omitted.

Matlab usage has been in decline for many years.

Matlab is one of the top 20 programming languages in the world still after 60 years according to the TIOBE index [0]. It has maintained a large user-base and achieved profitability over this time, not by adopting every PL trend that has come and gone, but by adapting to new developments while staying focused on its essence as a language. It proves you can stay current without doing what C++ is doing. Matlab's usage i…

Citing TIOBE instantly demonstrates a fatally bankrupt argument: changes in TIOBE ratings have essentially nothing to do with actual usage, or with anything else quantifiable.

TIOBE is statistical noise. You would equally meaningfully cite your tea leaves, or crows flying overhead.

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

#470

Post by ncmncm »

ModernMech wrote: post #447
ncmncm wrote: post #430

Earlier quoted context omitted.

You are very confused. People not using the latest Standard are waiting for support within their particular environment, not because they want to stay with a less performant version of the language.

But they’re still not on the latest version…

People not using the latest Standard are waiting for support within their particular environment, not because they want to stay with a less performant version of the language.
Post reply on HN