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.
@belvo people who believe in OOP a lot will try to talk about Programmer time and the cost of a programmer, which is true. But they ignore the fact that the principles of good design are not limited to OOP. You can design a usable, decoupled system without it, and not be stuck in the mindset that requires things like data hiding, interfaces for everything, dynamic allocations for everything, etc.
@belvo for example using the statement before: imagine you write Swift and you process a large amount of data enclosed in classes. You put those classes in an Array and process them in a thread. This runs slow but you have optimized every instruction.
Now, changing to ContiguousArray might get you better cache performance, but requires your class be a struct, a huge breaking change that could have massive impacts everywhere that class is used, depending on how its used.