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

431–440 of 516 posts

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

#431

Post by ncmncm »

lanstin wrote: post #388
ncmncm wrote: post #361

Earlier quoted context omitted.

In other words, talk. Like on HN. Respectable doesn't mean used.

The respectable comment was conditional on it landing in the Linux kernel - I'd be impressed by that. I'm not really aware of any large projects written in Rust, which I find to be a bit of a red flag. There was a project to re-write all the core-utils and such from Gnu in Rust, but I don't think it's gone anywhere. It wouldn't be that much fun because you'd have to replicate all the long options and existing complex…

The Linux thing is just politics. Rust has all the features Linus insisted he hated most about C++.

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

#432

Post by ncmncm »

astrange wrote: post #416
ncmncm wrote: post #357

Earlier quoted context omitted.

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…

> When hinting branches gives you a bigger L1 cache footprint, it has a high cost. It was the same size on PPC, and on x86 using recommended branch directions (but not prefixes). > 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"?) Hot/cold splitting is not just sinking unlikely basic blocks, it's when you move th…

It suffices, for cache footprint, for cold code to be on a different cache line, maybe 64 bytes away. For virtual memory footprint, being on another page suffices, ~4k away. Nothing benefits from being at the "end of the program".

Machines do still charge an extra cycle for branches taken vs. not, so it matters whether you expect to take it.

Negligibly few things never return; most of those abort. Performance of those absolutely does not matter.

Why should anyone care about predicting the catch block a throw will land in after all the right destructor calls have finished? We have already established that throwing costs multiple L3 cache misses, if not actual page faults.

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

#433

Post by jcelerier »

nemothekid wrote: post #305
cesaref wrote: post #231

Earlier quoted context omitted.

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

I'm not sure I understand the appeal of C++ exceptions. For years I've been told that Rust and Go's lack of advanced exception support is a crutch; and that error returns or sum types were unimaginative. Now, in this thread, exceptions are supposed to be used rarely. I don't see the difference between an exception and Rust/Go's `panic`. If the error is rare enough, then chances are you cannot gracefully recover. If t…

> If the error is rare enough, then chances are you cannot gracefully recover.

that does not match my experience. Generally, rolling back to the state at the beginning of whatever user interaction caused the exception is good enough in a large amount of cases and a much better experience for end-users than abort()

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

#434

Post by pjmlp »

duped wrote: post #89
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…

I think I agree with the sentiment but not the example, no one seriously advocates for no-new/no-delete (collections must still be written, somewhere) but rather that new/delete are generally code smell and there are idioms that can help isolate bugs. Part of maintaining old code is updating to those idioms. But yea this kind of thing hit me recently on the interview circuit. I wrote some correct C++ (in that it was…

To be fair I imagine the same happening to someone coming to a Java interview still writing Java 8, or writing C# as if .NET Framework 4.8 is the latest version (C# 7.3).

It doesn't happen only in C++ circles.

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

#435

Post by pjmlp »

dureuill wrote: post #205
zozbot234 wrote: post #130

Earlier quoted context omitted.

> it still seems like it has settled into a lower-frequency churn rate lately for "best practices" than C++. Rust is still adding a ton of new language features, especially around async, compile time code evaluation and the type system (const generics, GAT/HKT, existential types etc.). We'll very likely see further developments in more areas next, e.g. to match C++ developments in parallel and heterogenous compute (G…

I'm not convinced they're comparable. C++20 is adding a module system to C++. That's a major change to the compilation model. It is also adding concepts, a major change in the way templates are to be written. The very article we're commenting on is discussing how exceptions should possibly be replaced by another error report mechanism, several proposals are in flight for this. There's also the "destructive moves" pro…

> It is also adding concepts, a major change in the way templates are to be written.

Indeed, instead of crazy tricks with SFINAE and tag dispatch, templates can be much easily written.

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

#436

Post by jstimpfle »

ncmncm wrote: post #415
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…

Without exceptions, you will hit a performance problem on every single call , successful or not. That is what happens at Google, and in Rust: almost every last call site in the whole system has a "if" check. I.e., it is both badly obscured, and also slow. You are arguing that programmers should not be obliged to make judicious choices. But that is exactly the job of every programmer. Dodging consequential choices pra…

I can't imagine error-checking if's being a source of slowness. How are exceptions generated in the first place? Using if's. And anyway, even well structured code is full of if's (e.g. array iteration), and it's not a problem. Especially for error-checking, when the error case is rare, the CPU will correctly predict the branch to take most of the time, so the cost of the if is negligible.

The only call where if's should probably be minimized is on hot paths, where there shouldn't be any I/O or other exception code anyway.

I would agree that manual stack unwinding (many stack frames deep) by propating error values up the call chain is bad. The problem here is not the if's, but that the program structure is unnecessarily convoluted. This can happen when specific code is calling generic code a lot (which can be avoided by having the generic code call the specific code instead).

> You are writing bad code, and should be ashamed.

Woah, calm your horses!

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

#437

Post by Rexxar »

Koshkin wrote: post #360
zozbot234 wrote: post #195

Earlier quoted context omitted.

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.

The "necessity" is defined by the three foundational opinions of c++ :

- zero cost abstraction

- system language

- compatibility with C toolchain

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

#438

Post by pjmlp »

dtech wrote: post #170
layer8 wrote: post #129

Earlier quoted context omitted.

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+ l…

> There's a reason no other languages has them,

As always someone is wrong on Internet.

Java adopted a feature that was initially introduced in CLU, adopted by Mesa/Cedar, Modula-2+ and Modula-3, was being considered for ongoing ISO C++ standardization at the time.

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

#439

Post by pjmlp »

kevin_thibedeau wrote: post #211
jeffbee wrote: post #9

Earlier quoted context omitted.

You don't have to start over with the whole language. Just use -fno-exceptions in your project and dictate the use of std::optional, or absl::StatusOr, or whatever your favorite variant return type may be. For the examples in the article, it may be perfectly fine to not support failure, to simply std::abort whenever the sqrt of a non-positive is requested and rename the function sqrt_or_die.

You also have to abandon operator new and STL unless you want to pretend they never fail.

Just use the no_throw variant, no need to abandon new.

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

#440

Post by bogeholm »

ncmncm wrote: post #402
ModernMech wrote: post #380

Earlier quoted context omitted.

Fred Brooks put it this way: "I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas." IMO C++ does not have conceptual integrity.

A language that has stopped responding to the evolving needs of its user community is a dead language. C++ is not a dead language. Your complaint is that it is not dead.

I read OP’s complaint as “it is no coherent”
Post reply on HN