Hacker News Reader

Comment by chrisco255 | Hacker News Reader

If you understand how the CPU, memory, network, and disk are processing your program and its structures, you can design your programs to optimize for the hardware.

Full guide for ref: https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...

View on HN

True. The guide is an interesting read. When you are deep in the trenches, most of what the github link says is just common sense.

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

> if you understand how the CPU, memory, network, and disk are processing

I don't think it's possible in the general case, it's way too complex for that. Sure for trivial examples it's trivial to claim one program is faster than the other, but can you really claim that your special allocator used in one place plus the extra argument used in calling that function is worth it without writing both options and measuring it? Like even measuring it is non-trivial, will it be inlined at the use site, how is it called, etc.

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.

You'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"

Yeah, except the CPUs are complex, you might not understand ALL the details of a working program (like randomising memory layout).

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

The 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 on news.ycombinator.com