back
82 comments
"Is performance still an issue in this era of cheap 486 computers and super-fast Pentium computers? You bet. How many programs that you use really run so fast that you wouldn't be happier if they ran faster? We're so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, we're ecstatic—when in truth we should be settling for nothing less than instantaneous response."

Not sure if I want to laugh or cry at how 100% relevant this still is 20 years later...

I've had people tell me all of the extra bloat/slowness in modern software is because it has more features, and because accessibility / localization is a thing more often. I'm not sure I actually believe that's true. Maybe accessibility and localization contributes to bloat/slowness, but that doesn't mean it couldn't be much much more efficient and keep the same features.
Software is usually slow because most of the time developers don't get paid for runtime performance, but features.
The numbers don’t really add up. Computers are a hundred times (replace with actual value, but it should work even for a 10x increase) faster, yet the feature set hasn’t increased by anywhere near that factor. Also “feature” is a big word, usually a single feature doesn’t even eat up that much performance.

I think it’s rather — just as Moore’s Law — a psychological phenomenon rather than a mathematical one. There’s just so many seconds we’re willing to wait and at one point, we don’t even care. Also the Internet hardened us for long wait/download times.

Exactly this. Anyone who was gaming and "websurfing" back in the 90s will recognize that load times today are no better than back then, and are often times much worse.

And that view isn't a psychological rewrite of the past. I regularly game on systems from both the 90s and modern day, and the load times for modern games are usually much worse than the CD games of old. The funny thing is that people would complain like crazy about CD load times back then, even citing it as a reason why CDs could never become mainstream.

And yet, here we are present day with obscenely shitty load times for most software.

I think the one area that has improved dramatically has been video streaming though. Real Player and the like were terrible even for their time.

> I've had people tell me all of the extra bloat/slowness in modern software is because it has more features

Lately I've been making something of a hobby of replacing big scale-out Apache Spark ETL jobs with stuff that was hand-coded to use something other than Spark. Generally I'm finding that, with a little care, I can get a lot of these jobs done in less time on a single machine than I can running it on the Spark cluster. (Using code that's easier to reason about, too.) And even when I can't, I'm not sure it's enough slower to warrant the use of the cluster, on the principle that using half a rack worth of compute resources to get the job done in 45 minutes when you could do it in 60 on a single box isn't really a good tradeoff.

All that long-windedness by way of saying, these big data tools are kind of slow and bloated. They're slow and bloated precisely because they have more features. All the extra work they need to do to achieve reliability when you're scaling out has a cost. But that doesn't necessarily mean that the cost is justifiable.

A box truck is more capable for running errands than my Kia Soul, because I can fit half the grocery store in it. But I think we'd all agree that it would be an obscene waste of money to default to using a box truck to buy groceries and make Ikea runs, and justify that decision by pointing out that some small fraction of the time I'll need to transport more stuff than will fit in a Kia Soul, and it's better to standardize on a single model of car. In a computing setting, though, we do that sort of thing all the time.

It's a lot easier to hire someone to drive a box truck than it is to hire someone to drive your Kia.
I think people undersell the value of safety. Back in the 80's and 90's, it wasn't uncommon to drop into assembly to grab every last cycle of performance, since computers were so slow. We also didn't do garbage collection, and people were writing in languages like C and C++. Software from then was also prone to random crashes and freezes, which doesn't happen so much anymore.

We've started to come around with languages like Rust, but a lot of engineers have (in my opinion rightly) come to the conclusion that it's better to abuse the faster speed of computers to have a higher assurance of the software being correct. Could I conceivably get better performance if I wrote something in C and wrote a custom allocator? Maybe, but I'd probably make a mistake, and my GC'd language is fast enough for most of what I do.

Present day programs aren't optimized because they don't have to be. No one needs to gain a competitive advantage by squeezing the last bit of performance out of hardware because for a long time we've had steadily increasing performance levels and backward compatibility. Applications which need more performance than the present level of hardware can deliver so badly that they need to optimize to that level are very rare.

That's why Windows is the size it is nowadays... it's optimized for delivering the same user experience on all hardware, compatibility, language flexibility, manageability and user friendliness (don't laugh) instead of performance. It essentially performs the same function that Windows 3.1 did, but it does it on a far greater variety of hardware running a far larger assortment of software.

It's bigger and slower than it could be, but there are always trade-offs, and Microsoft hasn't really had any competition in operating systems for decades... Linux and variants have their place, but it's not on the desktop for most people, at least at the moment.

Sites that actually really care about accessibility, like gov.uk, seem to disprove the performance claim at least
Funny, in a thread just the other day I was asking why we use different icons in new updates and focus less on optimization. This was in response to a commentor that suggested apps will use all available resources. If graphics has taught me anything it's: use what you need and make it fast. Other programs are relying on you.
People take for granted that an app responds in milliseconds. Engineers at Google, et al, of course immediately recognized that performance was tied to adoption in the early days and left no stone unturned in their quest for optimizations. The analogy today in portable devices is maybe with battery life drain during game play.
I think with search results you're right, and with things like GMail it seems performance is at the bottom of the priority list. Perhaps even off of the priority list entirely.
This takes me back to the early nineties, when these articles where published in monthly installments in Doctor Dobbs Journal and, later, PC Techniques.

Incredibly, these 2 magazines were stocked monthly at my local newsstand in a sleepy suburb of Antwerp, Belgium, and every month around publication time, I’d bike there daily to check if the next issue had arrived.

I learned a lot of good stuff in college, but I don’t remember anything as exhilarating as this series, which eventually would lead to a career in the computer graphics industry.

I had the same experience (Belgium and Italy) - I would add in the same category the old Game Developer magazine, which had a regular series on game physics and math. Still have a bunch of them. Those were the days :-)
This is such an awesome book. I read this back in the day and loved every minute of it.

I think there is a lot to learn from it still, even if you're highly unlikely to be writing the same kind of graphics code.

The book has a great balance between: - Micro-optimization - fiddling with ASM and data structures, memory alignment and such, custom math functions that lose precision in tradeoff for great acceleration due to hardware features

- Algorithmic optimization - trying to do things in ways that are mathematically faster (computational complexity)

I work in enterprise software, not games or anything touching hardware.. it is depressing algorithmic complexity is ignored so often these days and if you give an interview question it is often greeted with blank stares and there seem to be college undergrad curriculums which don't even touch on it.

I'm in that camp that feels like software has gotten so inefficient in a lot of cases that the user experience is no faster than 20 years ago. We have acceleration & optimization for certain things but every day applications are no faster than they ever were and when you have to use a web application stuff is often a lot slower than a native app was 10-20 years ago.

There are still a lot of great college texts on computational complexity even though trade publications ignore this stuff with a vengeance.

From my experience (graudated in 2016), most interviewing is centered around algorithmic complexity or at least regurgitating logarithmic complexity algos.

Potential hires still in or just out of school should have no problem answering those questions, but a few years out and most people forget those skills since most of the time the answer is to use an existing implementation or find a way to avoid the problem entirely. All of the people I know with a 4-year CS degree learned all about that stuff in their data structures/intro to algo classes.

I work in games and have had to both implement a few data structures on my own (mainly specialized trees and graphs). I've seen them help performance a ton and I've also had to scrap one or two of them because the naive implementation was faster. Nowadays a lot of indirection means your processor is spending most of it's time waiting on memory reads, while flat arrays can be loaded into CPU caches a lot more efficiently.

User interfaces are measurably slower than they were 20 years ago by at least an order of magnitude depending on how you measure it. They also do more, so it's up to the particular user and use case to decide if the trade off was good.

There was someone who said something along the lines of, "Heaven is old software on new hardware" and I personally agree with them.

I work in games doing mainly graphics work - it's amazing how many of these concepts still exist and have been recycled in interesting ways. Well worth the read if you're in my line of work.

For example, the concept of "sorted spans" in Quake is conceptually the same as how "light culling" is done in deferred and forward+ rendering pipelines. The first I'd heard of the technique was how Battlefield 3 used the PS3's SPU to do light culling for 64x64 blocks of pixels at a time.

This book is a great resource for thinking about how to optimize your code. And while VGA programming is not as relevant as it was, I still found it really fascinating to read about. Plus, the chapters on Quake are really interesting to read
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)
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...
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

I still keep the original version. I bought this book with very little money in 2001. Back then not many book covered algorithms.

I can hardly remember from todays perspective how it was looking after some code snippets in books without google, github, stackoverflow, strg+f.

The best part of the book is the part about The Kennedy Portfolio, in Chapter 9. "Reader John Kennedy regularly passes along intriguing assembly programming tricks, many of which I've never seen mentioned anywhere else."
I wrote a game of life screensaver for Windows years ago using the optimizations recommended by this book in C# if anyone is interested. https://github.com/masterwok/Game-of-Life-Screensaver
This is great, but I can't seem to find a generated version? A PDF for example would be nice?
A while ago I bought the paperback version of this book since I hate reading on the computer. It's huge, was $100 on Amazon, and someone wrote "Trash" on the side before they realized they could sell it.

And to think now I have a Kindle... >.<

Thank you for making this available. I had the original book which unfortunately went missing between moves. A great book!
I read "Graphic Programming Black Block" and for a moment thought that the demoscene had an awesome revival!
I read it long time ago, good book!
> Markdown source (2001)

This looked like a peculiar anachronism, as Markdown was created in 2004. But apparently this isn't the original source, but rather a scraped HTML[1] version converted to Markdown[2] in 2013.

1: https://github.com/jagregory/abrash-black-book/commit/b946ff...

2: https://github.com/jagregory/abrash-black-book/commit/5e1079...

Repo owner here. You are correct, not sure why this wasn’t made clearer by OP.

Book released 1997, made available online in 2001, converted to Markdown/ePub/etc by me in 2013.

OP here. Sorry if there was confusion. I came across your repo and was giddy with excitement to see it and wanted to immediately tell the world! :-) This book was a big deal for me in the late 1990s, still working as a game programmer. My copies were lost or loaned and I think I heard angels sing (or tracker/chip tunes?) when I discovered your repo. ;-)

I suffixed the headline "2019 V1.1 Release", trying for some clarity, since that was the most recent event I saw in the repo. Then it was re-headlined by someone else because that was also, apparently, confusing. Sorry! But THANK YOU for your work!

Nice work. I don’t know if I’m ahead of the curve but iBooks on iPadOS beta 13.1 comes up with a resource error for the ePub; don’t try this at home kids.

I trust there’s a way to get iBooks log files to fix issues...

Could you also add PDF version? (converted from Markdown)
Out of curiosity, how did you do the html to markdown conversion?
To save others the disappointment of expecting a 2019 update, this is a cleaned-up copy of the classic text.
I don't think I'll ever be disappointed to see this work linked. :) In some ways I feel like modern graphics programming has little to do with traditional optimisation. Rather than coding tight inner loops and wizardly algorithms, it's all about managing cache lines and pipelining data flows into your massively parallel desktop supercomputer. Which is awesome, but compared to the older stuff it's like a high speed rail network compared to a motorbike.
There are still areas where you're very much "coding tight inner loops and wizardly algorithms", namely shader programming. But it's true this is only one component within the high speed rail network.
Just curious, is it OK to say that most of the book is irrelevant for today?
I'm actually wondering who is Wendy Tucker...