Naw, Quake was heavily optimized by some of the best x86+pixel gurus ever, like Michael Abrash. It look a lot of work to get there. But there have been cycle-optimized pixel graphics since the very first video game. Quake was also lower res and far simpler lighting and lower quality than modern games. Rendering pixels on the CPU without a metric ton of optimization effort was always slow, and exponentially slower the further back you go. GPUs are the primary thing making pixel rendering fast now, and it’s because of hardware and a parallel programming model, not because of software.

I might be biased because I do perf work and everyone I know does perf work, but I feel like there’s more people doing optimization now than there were total programmers 20 or 30 years ago. You’re not wrong, and there are plenty of people who write software and don’t feel the need to worry about perf because there aren’t any people that it slows down. Michael Abrash might agree with that being reasonable, since he defined optimization to mean perceptible wait time:

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

http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf