Jeff WardThere are very few more heated arguments in this world that two C++ developers arguing about the correct way to do things.
This toot brought to you by the two day long argument I'm reading about `std::to_underlying` for C++ enum classes.
Also C++ devs who took Abrash's "measure to know the performance of something" waaaay to seriously.
Like, I can know certain practices hinder performance of things without measuring.
This is why SIMD APIs exist. Compilers are pretty magical, but they're not *that* magical.
This is something I find really really interesting about a lot of C++ devs. The language is supposed to be all about performance, but a lot of the arguments are about best practice within the language, proper architecture, avoiding footguns, and so often arguments specificly about high performance architectures are scoffed at in favor of "proper OOP" or assuming that you can't know something is high performance without measuring.
It's baffling.
As an aside, It reminds me of a discussion on some Swift forum about the performance of Arrays vs. ContiguousArray. Their testing showed no performance difference between the two (with Array actually being faster), and no one haad any answers as to why you would use one over the other.
The answer is cache that ContiguousArray can be more cache coherant in tight loops. But so few people know that and can come up with real tests that show the difference, so everyone just uses Array.
Belvo@fuzzybinary premature optimisation, no?
@belvo that is a very long and involved discussion.
The short(-ish) answer for me is that that statement really refers to algorithms over design. Internal algorithms are easy to change. Design is not. And some designs are just straight worse for performance on a modern cache based CPU.
The flip side of that statement is "Don't prematurely pessamize." And we unwittingly do it all the time, trapping ourselves into well intentioned complex OOP architectures that can't actually push performance.
@fuzzybinary I agree with all that! Probably it’s worth measuring performance at various intervals to properly assess which is implementation is better. Tiring and probably a bit slow, but science/experiment-driven
Time constraints tend to put a wrench in all that
Time constraints tend to put a wrench in all that
@belvo So, this was the general response from a co-worker. But we *know* cache misses are orders of magnitude slower than any other instruction issued by a CPU -- this is documented overhead. But a cache miss vs hit has so many prerequisetes that it's hard to even come up with artifical tests that will cause cache misses.
So data design becomes one of the few ways to ensure you're using your processor efficiently, and avoiding cache misses.
@belvo Mike is much better at talking about this btw: https://www.youtube.com/watch?v=rX0ItVEVjHc
CppCon 2014: Mike Acton "Data-Oriented Design and C++"
@belvo This slide in praticular sticks in my head: https://youtu.be/rX0ItVEVjHc?t=1831