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

31–40 of 85 posts

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

#31

Post by ben7799 »

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.

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

#32

Post by pierrec »

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…

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.

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

#33

Post by big_chungus »

app4soft wrote: post #25
jagregory wrote: post #6

Earlier quoted context omitted.

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.

Could you also add PDF version? (converted from Markdown)

You can add the following target to the Makefile:

  pdf:
          rm -f out/black-book.pdf
          pandoc --to pdf -t latex --pdf-engine=xelatex -o out/black-book.pdf --toc $(FILES)
Or here's a link to the copy I generated: https://u.teknik.io/pAxm9.pdf

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

#34

Post by anaphor »

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…

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.

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

#36

Post by floki999 »

tverbeure wrote: post #26

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

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

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

#37

Post by vardump »

Ono-Sendai wrote: post #19
raverbashing wrote: post #13

Earlier quoted context omitted.

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.

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.

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

#38

Post by vardump »

anaphor wrote: post #34
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…

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.

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

#39

Post by robmaister »

ben7799 wrote: post #31

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…

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.

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

#40

Post by criddell »

naikrovek wrote: post #21
ArtWomb wrote: post #20

Earlier quoted context omitted.

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.

I sometimes wonder if GMail users are expected to leave it open all day long. I bet that's how most Googlers work.
Post reply on HN