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

41–50 of 85 posts

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

#41

Post by Accujack »

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.

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.

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

#42

Post by tombert »

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.

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.

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

#43

Post by entropicdrifter »

criddell wrote: post #40
naikrovek wrote: post #21

Earlier quoted context omitted.

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.

I keep a tab pinned in Firefox. Runs great if you never close and re-open it.

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

#44

Post by robmaister »

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.

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

#45

Post by godelski »

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…

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.

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

#46

Post by vanderZwan »

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.

Sites that actually really care about accessibility, like gov.uk, seem to disprove the performance claim at least

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

#47

Post by nothis »

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.

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.

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

#48

Post by slowhand09 »

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…

I would disagree with the "they don't need to be" stmt. Many photographers and artist have legit gripes in the lengthy time many filters and transforms take in post processing. Many of these are recipes that are applied en-masse to all files in a directory.

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

#49

Post by mumblemumble »

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.

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

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

#50

Post by inflatableDodo »

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.

Hardware matters.
Post reply on HN