4 ms·

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 lar

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.

gumby 5y ago
> 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.
- JoeAltmaier 5y ago
  You're right, the issue is convoluted and nuanced. There are architecture issues, cache sizes and layers to consider, cost of misses and writes, alignment and bus sizes. Oh for the good ol days when register size was all you had to think about!
gumby 5y ago
> But there's a design pattern where nearly everything is returned as an exception. shudder The worst of cargo cults!
- catskul2 5y ago
  Is "cargo cult" really what you mean here. It doesn't seem to fit.
  - gumby 5y ago
    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.
    - ncmncm 5y ago
      Most design patterns are anti-patterns: they represent a failure of the language to offer a way to abstract the pattern into a component or native language construct. It is usually better if it can be captured in a library. But sometimes, particularly in weak languages, nothing but core language support will do. A fancy core language feature should embarrass the language designer. Sometimes, a language evolves to the point where a core feature could be as well implemented as a library component. That is a marker of real progress, because now the feature can be offered in a dozen variations in a dozen libraries, each tailored to local conditions, where the core feature had to ruthlessly ignore all but the most generic use cases.
deleted 5y ago
[deleted]
josephg 5y ago
> But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. The problem isn’t that C++ exceptions are slow when used the way the compiler expects. The problem is a mismatch between how C++ expects you to use the feature, and how people are actually using the feature. I can’t find the story now, but I read about this happening with Ruby on Rails. Someone dug into why rails was so slow at Twitter, and found the way rails was looping through an array was that it would loop unbounded, and catch and discard the array out of bounds exception at the end of the loop. Whenever Ruby throws, it allocates 10k of memory and fills it with all sorts of information for debugging - including a full stack trace. And it was doing this work in the background every time someone iterated through an array. Fixing this resulted in a massive speed up at Twitter, and presumably across the entire rails ecosystem. I saw the same thing at (big tech company) a decade or so ago. I was working on a project which used GWT. We brought some people in to help us optimize, because the program was too slow. The first thing they found was that the JS VM was spending most of its time in the exception handler for some reason. Turned out one of our engineers had a habit of using throw & catch as a way to do multi level returns in complex code in Java. But the exception was being converted to a javascript exception by GWT. And javascript exceptions are (were?) super slow. Y’all gotta stop using exceptions like that. I know it feels clever. But in most programming languages, using exceptions for control flow will kill your performance.
- LightMachine 5y ago
  > Whenever Ruby throws, it allocates 10k of memory and fills it with all sorts of information for debugging - including a full stack trace. And it was doing this work in the background every time someone iterated through an array. Jesus
- ATsch 5y ago
  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 they are only used for their intended purpose and are not abused as a general purpose control flow mechanism.
NoSorryCannot 5y ago
Exceptions have some of the properties of a discriminated union, which is why they're used this way. Sometimes it seems parsimonious compared to the alternatives.
throwuxiytayq 5y ago
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++?
- Koshkin 5y ago
  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.
  - renox 5y ago
    I wish unfortunately that's not my experience at work one developer used exception as a control flow with the excuse that it was on a non performance critical part of the code.. Annoyed me very much as it made gdb's 'catch throw' useless. So I reimplemented this code and the result was easier to read IMHO but of course I'm biased..

gumby 5y ago

> 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.

JoeAltmaier 5y ago
You're right, the issue is convoluted and nuanced. There are architecture issues, cache sizes and layers to consider, cost of misses and writes, alignment and bus sizes. Oh for the good ol days when register size was all you had to think about!

gumby 5y ago

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

catskul2 5y ago
Is "cargo cult" really what you mean here. It doesn't seem to fit.
- gumby 5y ago
  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.
  - ncmncm 5y ago
    Most design patterns are anti-patterns: they represent a failure of the language to offer a way to abstract the pattern into a component or native language construct. It is usually better if it can be captured in a library. But sometimes, particularly in weak languages, nothing but core language support will do. A fancy core language feature should embarrass the language designer. Sometimes, a language evolves to the point where a core feature could be as well implemented as a library component. That is a marker of real progress, because now the feature can be offered in a dozen variations in a dozen libraries, each tailored to local conditions, where the core feature had to ruthlessly ignore all but the most generic use cases.

deleted 5y ago

[deleted]

josephg 5y ago

> But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. The problem isn’t that C++ exceptions are slow when used the way the compiler expects. The problem is a mismatch between how C++ expects you to use the feature, and how people are actually using the feature. I can’t find the story now, but I read about this happening with Ruby on Rails. Someone dug into why rails was so slow at Twitter, and found the way rails was looping through an array was that it would loop unbounded, and catch and discard the array out of bounds exception at the end of the loop. Whenever Ruby throws, it allocates 10k of memory and fills it with all sorts of information for debugging - including a full stack trace. And it was doing this work in the background every time someone iterated through an array. Fixing this resulted in a massive speed up at Twitter, and presumably across the entire rails ecosystem. I saw the same thing at (big tech company) a decade or so ago. I was working on a project which used GWT. We brought some people in to help us optimize, because the program was too slow. The first thing they found was that the JS VM was spending most of its time in the exception handler for some reason. Turned out one of our engineers had a habit of using throw & catch as a way to do multi level returns in complex code in Java. But the exception was being converted to a javascript exception by GWT. And javascript exceptions are (were?) super slow. Y’all gotta stop using exceptions like that. I know it feels clever. But in most programming languages, using exceptions for control flow will kill your performance.

LightMachine 5y ago
> Whenever Ruby throws, it allocates 10k of memory and fills it with all sorts of information for debugging - including a full stack trace. And it was doing this work in the background every time someone iterated through an array. Jesus
ATsch 5y ago
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 they are only used for their intended purpose and are not abused as a general purpose control flow mechanism.

NoSorryCannot 5y ago

Exceptions have some of the properties of a discriminated union, which is why they're used this way. Sometimes it seems parsimonious compared to the alternatives.

throwuxiytayq 5y ago

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++?

Koshkin 5y ago
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.
- renox 5y ago
  I wish unfortunately that's not my experience at work one developer used exception as a control flow with the excuse that it was on a non performance critical part of the code.. Annoyed me very much as it made gdb's 'catch throw' useless. So I reimplemented this code and the result was easier to read IMHO but of course I'm biased..