Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graphics Programming Black Book by Michael Abrash (2001)

github.com

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Graphics Programming Black Book by Michael Abrash (2001)

#11

Post by taneq »

kranner wrote: post #2

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.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#12

Post by mysterydip »

phtrivier wrote: post #8

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)

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.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#13

Post by raverbashing »

mysterydip wrote: post #12
phtrivier wrote: post #8

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)

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

Re: Graphics Programming Black Book by Michael Abrash (2001)

#14

Post by boomlinde »

phtrivier wrote: post #8

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)

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.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#16

Post by markus_zhang »

taneq wrote: post #11
kranner wrote: post #2

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 ra…

Just curious, is it OK to say that most of the book is irrelevant for today?

Re: Graphics Programming Black Book by Michael Abrash (2001)

#18

Post by Shish2k »

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

Re: Graphics Programming Black Book by Michael Abrash (2001)

#19

Post by Ono-Sendai »

raverbashing wrote: post #13
mysterydip wrote: post #12

Earlier quoted context omitted.

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.

Re: Graphics Programming Black Book by Michael Abrash (2001)

#20

Post by ArtWomb »

Shish2k wrote: post #18

"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 tha…

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.
Post reply on HN