undefined

points

[-]

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

by austin-cheney9 hours ago|

parent|

[-]

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.

by nvme0n1p19 hours ago|

parent|

[-]

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"

by elendilm9 hours ago|

parent|

prev|

[-]

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.

by Ygg29 hours ago|

parent|

prev|

[-]

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

by chrisco2556 hours ago|

parent|

[-]

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.

by grg08 hours ago|

parent|

prev|

[-]

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.

by vlovich1237 hours ago|

prev|

[-]

While I don't agree TigerStyle inherently actually helps you with this, design and architectural mistakes don't usually get solved in the way you're describing. You sometimes have to rethink how to structure your entire codebase. Sometimes you can evolve an architectural improvement but sometimes it requires a complete rewrite and there's no way to get outside of that path dependency.

by rcxdude9 hours ago|

prev|

[-]

There's a different between fixing performance mistakes, which tend to be obvious in profiling as big hotspots, and designing for maximum performance, which requires that you start, really, with the specification of what your application is doing, then follow that through to architecture and design with a strong view to reducing unnecessary work and staying within the operations that can be done at high speed with current systems.

by Ar-Curunir8 hours ago|

parent|

[-]

And Zig doesn’t seem to help with most of that!

If you’re already in your spec thinking about performance concerns at that level, then you can get pretty good performance in almost any language, though some languages might make it a little (lot) easier than others. But again I don’t think eg Zig vs Rust would be a big perf difference there.

by narnarpapadaddy6 hours ago|

prev|

[-]

Most undergrad CS students go through an algorithms course and understand a bubble sort is inherently slower than a quick sort, no amount of optimization will get you past the fundamental n^2 time complexity. You can generalize those same analysis principles to whole architectures and distributed systems. If you don’t recognize that the server interactions your solution requires boils down to an n^2 algorithm, you’re in for a bad time. Unlike a function a live, deployed system is typically harder to evolve. Sometimes constraints like backwards compatibility are such that you simply can’t fix it.