Hacker News Reader

Comment by phtrivier | Hacker News Reader

Questions for experts: are part of this "timeless" and still relevant today, or is it mostly historical ? (Chapter titles like "Pushing the 286 and 386" are a bit scary :D)

View on HN

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.

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

Well, 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)

Sorry, 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 :)

It's definitely mostly historical but it is an excellent read anyway if you're interested in what kind of problems faced game developers at the time and to what lengths they had to go to solve it. The chapters about getting Quake rendering to a decent level along with John Carmack are great. So, strongly recommended if you're interested in the technology during that era, not so much if you're expecting a lot of technical information that is directly applicable to current day game/graphics development.

People are still releasing DOS games, intros and demos targeting old hardware, so to them even some of the specific techniques described in the book may be relevant. On a higher level the algorithms described may be useful in modern systems with simple frame buffers. On a yet higher level, the general attitude towards optimization and problem solving that the book promotes seems timeless to me.

I also think that there is always some value in understanding the past in order to make sense of what is relevant to you in the now and what will be in the future, so I don't fully agree that there is a historical-relevant dichotomy. If you have the time to spare you can dig into the details of e.g. WWI and come out of it with a better understanding of the current state of affairs.

If your point is that knowing the past is, in general, interesting to understand the future, then I broadly agree.

However, at some point, records of the past become full of anectodes and little details that don't translate to anything valuable. And I was wondering if this was the case here.

I should have pointed out that I actually read part of the black book back in 2003 (how times flies...) , and, back then, I was already wondering if the book was relevant because of the focus of assembly and pre-pentium chips.

So, seeing the book mentioned 16 years later made me wonder what I might have missed, besides the eternal truth of "measure before you optimize".

The most important part for me was chapter 1: "the best optimizer is between your ears". Before you go unrolling loops and doing bit shifts to shave time at the micro scale, see if there's a different way to do what you want at the macro scale. Different algorithm, data structure, etc.

I'd add one small thing (from the book): There Ain't No Such Thing as The Fastest Code

(A good sum up https://blog.codinghorror.com/there-aint-no-such-thing-as-th... )

There are multiple ways of optimizing a code with different caveats and advantages

Sometimes there is such a thing as the fastest code: http://forwardscattering.org/post/13

Edit: In the black book the 'ain't no such thing as the fastest code' seemed to be a bit of 'folksy' wisdom, illustrated by various anecdotes about fast code being upstaged by yet faster code.

However it rubs me a little the wrong way, considering that it's not actually a true statement as demonstrated in my link above.

You're right of course but I think we have to recognise that for all sufficiently complex problems Abrash' "folksy wisdom" is effectively true and, in his particular case, a good chapter title more than a statement of fact.

True on an ideal computer with absolutely no other software running and no cache effects, dependency chain stalls, branch prediction failures, and so on.

Software equivalent of a spherical cow.

Hardware matters.

Reply on news.ycombinator.com