4 ms·
Some parts are timeless, like this introduction in the first chapter about optimization: --- Understanding High Performance Before we can create high-perform
by Crinus 7y ago
Some parts are timeless, like this introduction in the first chapter about optimization:
---
Understanding High Performance
Before we can create high-performance code, we must understand what high performance is. The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed tasks so rapidly that it responds instantaneously, as far as the user is concerned. In other words, high-performance code should ideally run so fast that any further improvement in the code would be pointless.
Notice that the above definition most emphatically does not say anything about making the software as fast as possible. It also does not say anything about using assembly language, or an optimizing compiler, or, for that matter, a compiler at all. It also doesn't say anything about how the code was designed and written. What it does say is that high-performance code shouldn't get in the user's way—and that's all.
That's an important distinction, because all too many programmers think that assembly language, or the right compiler, or a particular high-level language, or a certain design approach is the answer to creating high-performance code. They're not, any more than choosing a certain set of tools is the key to building a house. You do indeed need tools to build a house, but any of many sets of tools will do. You also need a blueprint, an understanding of everything that goes into a house, and the ability to use the tools.
Likewise, high-performance programming requires a clear understanding of the purpose of the software being built, an overall program design, algorithms for implementing particular tasks, an understanding of what the computer can do and of what all relevant software is doing—and solid programming skills, preferably using an optimizing compiler or assembly language. The optimization at the end is just the finishing touch, however.
- ryandrake 7y agoThink about the software you work on and maintain day to day: how much of it runs so fast that any further improvement in the code would be pointless? Truly we have strayed far from the light...
- Crinus 7y agoWell, i work in a AAA game engine that needs to run on consoles, so... :-P (though i work mostly on tools nowadays but even then, optimization is important - from my experience people wont tell you that the tool is slow, but they'll really like it if you make it faster, which is why i always dismiss comments like "people like Electron/otherslowstuff, otherwise they wouldn't use it" as way more often than not, people wont tell you about something being slow and they'd rather get used to it, unless it REALLY affects them in a major way)
- ryandrake 7y agoSorry, when I said "you" I meant the average "HN you", who tend to have 4 abstraction layers and 5 third-party frameworks between their users and the metal :)