I too am in the "premature optimization bad" camp.
Beyond the low-hanging fruit like ensuring you aren't creating O(n^2) complexity by accident, I think C++ is fast enough/has mature-enough compilers that by the time you're worrying about cache hits materially affecting performance, you're probably also sufficiently staffed and capitalized to pay people to A/B test that performance.
1. Compilers barely do even basic optimisations such as interprocedural register allocation when faced with non-trivial code.
You often also need the most aggressive optimisation settings, LTO or even PGO enabled for many of these.
2. Virtuals are, with the exception of PGO, mostly a black box i.e. you get a hard optimisation boundary, no inlining at all.
3. The C++ standard library is usually comically slow (yes, even compared to Java/C#/the likes) so if your project uses std::vector and the such instead of specialised libraries, you've already lost at the beginning.
4. If you don't pay attention to performance from the get-go, the approximate amount of autovectorisation you'll get is close to zero. Some compilers are better than others (Clang>MSVC for example) but I've seen codebases with 8 figures of LoC where the number of vectorised divides/multiplys was like less than ten when you dumped the object listing. In the whole program.
5. Since aliasing and other optimisation barriers (you didn't use restrict or manually hoist, did ya?), it's not uncommon for large C++ programs to spend a third of their runtime doing atomic increments because shared_ptr is supposedly cheap and who cares about lifetimes anyway.
6. If you're targeting Windows, the default new operator / malloc is also comically slow. Luckily that one is fairly easy to fix with installing mimalloc and deploying the hijack dll, but the negative effects on cache by the fragmented allocations is also significant.
Regarding 5., I have fortunately never seen a program overusing shared_ptr like that, but when I recently had a performance-sensitive use case for shared_ptr, I found boost::local_shared_ptr with non-atomic reference counting.
You really aren't in the "premature optimization bad" camp you just don't realize you optimize all the time but justify it as obvious. The main thing to know is that what is 'obvious' isn't unless you are profiling.
I don't know if this advice is strictly advocating to avoid premature optimization. Many problems are modeled intuitively with lots of tiny allocations and pointer heavy structures, and this advice is saying to avoid that.
I think it's more like: prioritize cache locality over big O compexity.
I don’t understand the question. Are you implying someone cannot know how to do something in a particular codebase unless they’ve already done it on that same codebase?
I don't really agree because it's so hard to reform a full application that's been written without regard to performance, after it's been written. You really need to pay attention from the beginning.
Open source continues its streak of picking atrocious names. Just off the top of my head, in recent memory we have Raku, Kodi, Luanti, Valkey, and now Nura.
Naming things is famously hard, but sometimes it feels like the Good Idea Fairy visits these projects and they aren't product-savvy enough to realize that humans are social, fickle creatures. You need to pick a name that your users won't be embarassed to say in a board room. There is a fairly sizable body of research-backed evidence that picking a cringe name reduces initial trust/comprehension.
Lukewarm take: "I'm a Raku developer" makes one sound like someone with poor hygiene who watches far too much anime.
Edit: also “floorp” the Firefox fork and “xonaly” the search engine. Who could forget those gems.
>The meme is that devs would copy and paste and hope it worked. The reality was more like you had an obscure bug, you wrote a detailed and cohesive question, and you connected with people who were more knowledgable and would help you.
Au contraire, the reality was more like you had an obscure bug, you wrote a detailed and cohesive question, and it was immediately closed as a duplicate of something unrelated but with a superficially-similar name from 5 years prior, and then you were threatened with a ban.
StackOverflow was easily one of the most toxic communities on the internet and I don't miss it.
Not sure about the rest but you should be skeptical about anything that serial grifter says.
This is the guy so out of touch he thought it was a good look to post about how having LLMs summarize your children’s lives to you in a podcast was a “cool idea”.
He’s the reason Ilya and the other top talent left OpenAI.
Diplomacy can be really, really, fun but you absolutely have to play it with the right crowd. It's an acquired taste because you spend a huge chunk of the game telling bald-faced lies and talking out both sides of your mouth. Some people are good at not taking things personally, or having hurt feelings after the game has ended.
>DHH has only written web software and knows nothing about serious software development.
I don't particularly like DHH either but web software is definitely serious. Shopify (which you seem to have confused with Spotify) runs on Rails. So does GitHub.
Those are both huge platforms handling a ton of traffic. If GitHub isn't "serious software" then what is?
Years and years ago I wrote a PWA for my wife and I to sync lists (packing lists, groceries, TODOs etc) cross-device. It's been running in a docker container and only goes down when the server reboots for kernel upgrades. That's at least five 9s of reliability. It has 2 users.
>If you're in a shooting war, the ability to select good military targets faster than your enemy, but not necessarily with zero error, is an advantage.
I mean, yes and no. Merely selecting the targets is not really an advantage in and of itself. I'm sure Iran could select hundreds of targets in the 48 States at the drop of a hat, but they don't have the air power to hit those targets so the air tasking cycle breaks down.
The air tasking cycle upon which modern NATO air campaigns are predicated and carried out is a cyclical 6-step process:
1. objectives not yet met/effects required
2. target development/selection to deliver those effects/meet those objectives
3. weaponeering, allocation, prioritization (can a hellfire launched from a drone do this or do we need something more specialized?)
4. actually write and issue the air tasking orders that cause air sorties to be flown
5. execution of said ATOs
6. assessment; GOTO 1
Normally this is a 72-hour cycle and your ops centre would be running 3+ of these cycles in overlapping fashion so that every 12-24 hours you have one loop reaching the top. AI appears to be in heavy use in the target development step, but there are diminishing returns for speed here. At some point there's just no added benefit for choosing more targets because aircraft can only transit to/from the area so fast. Also the other loops are still running and you're potentially developing targets without knowledge of effects being delivered by the other ATO loops so you're now wasting effort. In other words it's not like a computer where more hertz is better; you might get better results by simply waiting for one of the other cycle's kinetic results that will better inform your own target development stage.
Beyond the low-hanging fruit like ensuring you aren't creating O(n^2) complexity by accident, I think C++ is fast enough/has mature-enough compilers that by the time you're worrying about cache hits materially affecting performance, you're probably also sufficiently staffed and capitalized to pay people to A/B test that performance.
reply