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

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!

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

> 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

Twitter's Ruby on Rails problem that the parent mentions - @26:30 https://youtu.be/LjFM8vw3pbU?t=1591

Thats the one - thankyou! Its interesting that google doesn't index the transcript of youtube talks.

Great detail I'd forgotten: At the time twitter took 460ms of compute to process each request. Almost all the CPU time was in bcopy, constructing the big string backtraces for exceptions (that were then being immediately discarded).

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.

> 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 binary / JS bundle? What parts take up most of the space?

- When your program runs, what does the computer spend most of its time executing? What parts of your program are the slowest, and why?

- How big is the memory footprint? Which parts of your program use the most RAM?

For binary programs (like rust / Go / C), which patterns are easier or harder for the optimizer?

If there are two ways to design your code, how do you discover which approach will run faster?

This stuff shouldn't be considered advanced concepts. An architect understands the building they've designed. A chef knows what their food tastes like. When you program, you're making a thing. You should understand what you made and how it will be executed on the computer.

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.

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.

> But there's a design pattern where nearly everything is returned as an exception.

shudder The worst of cargo cults!

Is "cargo cult" really what you mean here. It doesn't seem to fit.

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.

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.

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

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.

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