221–230 of 516 posts
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.
Earlier quoted context omitted.
> and 1% of your tasks fail That's a lot of failures. I'd question whether or not you should be using exceptions for something that happens 1% of the time all the time. Admittedly you might not have any choice in the matter if it's a dependency that is failing.
The "exceptions should be exceptional aka rare" line sounds aspirational, but I wonder how true it is if you survey the general landscape of actual libraries.
I've done it exactly once and I ended up removing it because it makes debugging exceptions that you care about really annoying.
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…
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.
Earlier quoted context omitted.
> How exceptional exceptions really are depends on the code being run. Well yes, but EH is basically trying to be the best way to do a highly non-local goto with a dynamic target. If that part is your bottleneck than indeed you may have a more specialized requirement. I do on occasion build a homemade version of a standard library datatype because I have a specialized need and only need implement the subset our code…
I agree. I'm not sure breaking the ABI to fix the unwinder serialization issue should be a show-stopper, considering that there still isn't a C++ ABI.
In any case this doesn't seem to be an ABI issue
Earlier quoted context omitted.
> and 1% of your tasks fail That's a lot of failures. I'd question whether or not you should be using exceptions for something that happens 1% of the time all the time. Admittedly you might not have any choice in the matter if it's a dependency that is failing.
The "exceptions should be exceptional aka rare" line sounds aspirational, but I wonder how true it is if you survey the general landscape of actual libraries.
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.
Indeed, though I am shocked when people post benchmarks in which they are obviously unaware of this issue. It's why compilers have all those architecture switches.
If I understand your comment correctly: in the case of the posted paper, the compiler optimization issue the author mentioned was a semantics issue, not an architecture issue. If your comment was about optimizing for the multiprocessor case, I apologize.
Earlier quoted context omitted.
Are you arguing that C++ is unsuitable for massive parallel data processing tasks?
I think he's arguing that C++ exceptions are unsuitable for parallel data processing, at least in cases where exceptions are regularly thrown.
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…
That is, the checked part is just a language implementation, right? The jvm doesn't really make much of a distinction. (This is meant as a check to my assumption.)
I manage 1.2MLOC C++ developed over 25 years. I am pleased to say we never had to use exceptions. Just check the return value.