3 ms·

Writing Efficient Programs (1990)

47 points by dedalus 11y ago

nine_k 11y ago
Read this text from 1982 (33 years ago) and wonder at the great lengths one had to go to write efficient programs at the age of scarce computational resources and simplistic compilers.
- wirrbel 11y ago
  essentially, a majority of these tips still hold true. While nowadays you might get through with writing inefficient code, you will end up hitting a performance limit and all of the sudden, you are in the same situation as in '82.
- barrkel 11y ago
  Sometimes you need to go further today, due to the complex and capricious compilers. Not so long ago, I had to write a piece of Java code that sniffed a text file and tried to guess its encoding. The submitted files could be over a gigabyte in size - speed was a concern. We decided to support three main cases: pure ASCII, UTF8, and final fall-back to Windows-1252 in case of invalid UTF8 sequences. The idea being that the most common non-UTF8 file we'd have to support came from Western European Windows machines, and customers could always convert to UTF8 in case of encoding problems. Writing the Java loop for scanning over the bytes, testing for high bits and UTF8 sequences, was interesting. Manual loop unrolling was a win when the loop body was complex, but an even bigger win was making the loop body extremely simple and making it break out whenever a high bit was seen; in this case, Hotspot did the unrolling itself. The simpler the code, the more reliably the JVM could unroll and hoist array bounds checking out. The final code walked a tightrope between getting more work with fewer branches, and less work so that Hotspot could optimize. Try to do a tiny bit too much, and performance fell off a cliff. Looking at the generated assembly was still worthwhile to get an estimate of how much performance the JVM was leaving on the table, and whether or not it was worth working harder to extract it.
TickleSteve 11y ago
All these still apply equally well today, but most have forgotten about them. If you want to any form of performance or efficiency, you still need to pay attention to these.
Narishma 11y ago
The article is from 1990, but the book it is summarizing is from 1982.

47 points by dedalus 11y ago

Read this text from 1982 (33 years ago) and wonder at the great lengths one had to go to write efficient programs at the age of scarce computational resources and simplistic compilers.

wirrbel 11y ago
essentially, a majority of these tips still hold true. While nowadays you might get through with writing inefficient code, you will end up hitting a performance limit and all of the sudden, you are in the same situation as in '82.
barrkel 11y ago
Sometimes you need to go further today, due to the complex and capricious compilers. Not so long ago, I had to write a piece of Java code that sniffed a text file and tried to guess its encoding. The submitted files could be over a gigabyte in size - speed was a concern. We decided to support three main cases: pure ASCII, UTF8, and final fall-back to Windows-1252 in case of invalid UTF8 sequences. The idea being that the most common non-UTF8 file we'd have to support came from Western European Windows machines, and customers could always convert to UTF8 in case of encoding problems. Writing the Java loop for scanning over the bytes, testing for high bits and UTF8 sequences, was interesting. Manual loop unrolling was a win when the loop body was complex, but an even bigger win was making the loop body extremely simple and making it break out whenever a high bit was seen; in this case, Hotspot did the unrolling itself. The simpler the code, the more reliably the JVM could unroll and hoist array bounds checking out. The final code walked a tightrope between getting more work with fewer branches, and less work so that Hotspot could optimize. Try to do a tiny bit too much, and performance fell off a cliff. Looking at the generated assembly was still worthwhile to get an estimate of how much performance the JVM was leaving on the table, and whether or not it was worth working harder to extract it.

TickleSteve 11y ago

All these still apply equally well today, but most have forgotten about them. If you want to any form of performance or efficiency, you still need to pay attention to these.

Narishma 11y ago

The article is from 1990, but the book it is summarizing is from 1982.