Graphics Programming Black Book by Michael Abrash (2001) • Hacker News Board

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

#81

Post by pjmlp » Fri, Sep 06, 2019, 11:11 AM UTC

Accujack wrote: post #41

anaphor wrote: post #34

Earlier quoted context omitted.

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.

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

FOSS devs embracing Electron also does wonders for user expectations.

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

#82

Post by pjmlp » Fri, Sep 06, 2019, 11:20 AM UTC

tombert wrote: post #42

anaphor wrote: post #34

Earlier quoted context omitted.

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.

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

Back in those days some of us were actually using compilers for Pascal dialects, Basic dialects, with C and C++ being yet another set of languages.

Then C++ started to gain market share on OS/2, Windows, BeOS, Epoch, macOS, Newton as the way to write UIs, even if their kernels and low level APIs were written in C, or C with C++ compiler style.

All C++ libraries bundled with compilers, provided strings and vector types with bounds checking.

It was the rise of C's adoption thanks to FOSS that brought the unsafety wrath upon us.

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

#83

Post by pjmlp » Fri, Sep 06, 2019, 11:22 AM UTC

tombert wrote: post #54

hgoel wrote: post #52

Earlier quoted context omitted.

One can have safety without the absurd bloat though.

I agree with you in theory (hence why I gave a nod to Rust), but I think it's easier to have safe, bloated software. I think newer languages like Rust and Swift definitely are demonstrating the ability to have lean software that is just as fast as something written in C, but these are still relatively new in the scope of things. Much as I think Java is a garbage language, there's no doubt that, by default, it's safer…

Check DoD's security report about Multics and how it avoids typical UNIX exploits thanks to PL/I instead of C.

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

#84

Post by ryandrake » Fri, Sep 06, 2019, 7:06 PM UTC

Crinus wrote: post #80

ryandrake wrote: post #76

Earlier quoted context omitted.

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…

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

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

#85

Post by phtrivier » Sun, Sep 08, 2019, 8:21 AM UTC

boomlinde wrote: post #14

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

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