Code Performance:

  • [アーティクル]

I read coding horror. It is a good blog. I just read about the Graphics Programing Black Book. Yes if you click the link you will see it is freely available at byte.com. Jeff says the book is pretty darn good even if you don't ever do graphics programming, never write code in C and don't know nothin' about Assembly Language. So what the hell... I took a peek...

Excellent example of how humor can make anything more interesting. Specially a book on technology. Without humor and spice, any book would be dry. How beautifully he makes the book worth reading. From Technical standpoint and from a literary perspective too...!

I haven't read the whole book yet, but some beautiful extracts from the few initial chapters.

Chapter 1:

In the early 1970s, as the first hand-held calculatorsw ere hitting the market, I knew a fellow named Irwin. He was a good student, and was planning to be an engineer. Being an engineer back then meant knowing how to use a slide rule, and Irwin could jockey a slipstick with the best of them. In fact, he was so good that he challenged a fellow with a calculator to a duel-and won, becoming a local legend in the process.

When you get right down to it, though, Irwin was spitting into the wind. In a few short years his hard-earned slipstick skills would be worthless, and the entire discipline would be essentially wiped from the face of the earth. What’s more, anyone with half a brain could see that changeover coming, Irwin had basically wasted the considerable effort and time he had spent optimizing his soon-to-be-obsolete skills.

What does all this have to do with programming? Plenty. When you spend time optimizing poorly designed assembly code, or when you count on an optimizing compiler to make your code fast, you’re wasting the optimization, much as Irwin did.

Chapter 3:

When you are pushing the envelope in writing Optimized PC Code, you are likely to become more than a little compulsive about finding approaches that let you wring more speed from your computer. In the process you are bound to make mistakes, which is fine - as long as you watch for those mistakes and learn from them.

A case in point. A few years back, I came across an article about 8088 assembly language called "Optimizing for speed". Now "Optimize" is not a word to be used lightly. Webster's ninth new collegiate dictionary defines "optimize" as "To make as perfect, effective, or functional as possible", which certainly leaves little room for error. The author had, however, chosen a small, well defined 8088 assembly language routine to refine, consisting of about 30 instructions that did nothing more than expand 8 bits to 16 bits by duplicating each bit.

The author of "Optimizing" had clearly fine tuned the code with care, examining alternating instructions sequences and adding up cycles until he arrived at an implementation he calculated to be nearly 50 percent faster than the original routine. In short, he had used all the information at his disposal to improve his code, and had, as a result, saved cycles by the bushel. There was in fact only one slight problem with the optimized version of the routine.

It ran slower than the original version...!!!

Chapter 10:

My grandfather does the New York Times crossword puzzle every Sunday. In Ink. With nary a blemish.

The relevance of which will become apparent in a trice.

What my grandfather is, is a pattern matcher, par excellence. You are a pattern matcher too, so am I. We can't help it; it comes with the territory. Try focusing on text and not reading. Can't do it. Can you hear the voice of someone you know and not recognize it? I can't. And how in the nine billion names of God is it that we are instantly able to recognize one face out of the thousands we have seen in our life times - even years later, from a different angle, and in different light. Although we take them for granted, our pattern making capabilities are a miracle on the order of loaves and fishes.

By "Pattern Matching" I mean more than just recognition, though. I mean that we are generally able to take complex and often seemingly woefully inadequately data, instantaneously match it with an incredibly flexible way, to our past experience, extrapolate, and reach amazing conclusions, something that computers can scarcely do at all. Crossword puzzles are an excellent example; given a couple of letters and a cryptic clue, we are somehow able to come up with one out of several hundred thousand words that we know. Try writing a program to do that! What's more, we don't process data, in a serial brute force way that the computers do. Solutions tend to be virtually instantaneous or not at all. None of thos "N log N" or "n2" execution times for us.

Comments