This is also true for garbage collected languages, JavaScript in my case, but it requires a custom profiler and a bit more digging while asking better questions.
replyYou'll have a more direct path towards better performance if the questions you're asking are closer to "how does a CPU work", and further away from "what hoops do I have to jump through in 2026 to avoid optimization bailouts after V8's latest round of changes"
replyTrue. The guide is an interesting read. When you are deep in the trenches, most of what the github link says is just common sense.
replyEg: < Optimize for the slowest resources first (network, disk, memory, CPU) in that order, after compensating for the frequency of usage, because faster resources may be used many times more. For example, a memory cache miss may be as expensive as a disk fsync, if it happens many times more.>
This is just obvious common sense. Great read.
Yeah, except the CPUs are complex, you might not understand ALL the details of a working program (like randomising memory layout).
replyPlus not all speed-ups are made equal. Some speedups of a part of program can have no or even negative impact (as in making part of program faster slows down overall program execution).
No doubt, they are complex and you can't factor for everything, but I suspect that just even a cursory understanding of some broad characteristics across hardware will help you to design faster software when using a low-level language (and to some extent when using higher level languages as well), and your software will probably achieve must faster speeds than focusing on exotic design patterns in your software, for example.
replyThe truth is really a middle ground and the fact that you won't get the design right the first time around until you have built that hardware programming experience and learned from past mistakes. But this statement doesn't make for a good marketing stunt.
reply