Every Cycle is Sacred
Until about a year ago I'd spent a good four or five years doing Windows CE programming. Not application programming, but OS/OAL/bootloader programming. Now I'm working on code that runs on a 16 or 33MHz Dragonball (68328) processor and it's so much more satisfying.
The CE machines had clocks running at several hundred megaHertz, 32-64 megabytes of RAM and FLASH. The machines I'm working with now have only 256kB or 1MB of RAM and four or eight megabytes of FLASH. So how could I possibly be happier?
Every. Cycle. Counts. The fastest instruction takes four cycles, some take dozens (logical shifts). My first big project at this job involved choice between developing a new special-purpose algorithm or tuning a core routine. I compiled that core C routine to assembly and hand-optimised it. Lovingly hand-optimised it. The end result shaved 40% off the execution time. It's not that the compiler was bad, it actually did some very clever things, and I made sure I kept the good bits. Making this program run faster was interesting and challenging because I couldn't just throw a faster CPU or more RAM at the problem and make it go away.
Who does this anymore? Who knows how to do this anymore? Yes, I realise that hand-optimising assembly code for a non-stalling RISC processor is the fast path to insanity, but come on. Optimising isn't always about programming down to the bare metal, sometimes it just means thinking about the problem first. Just because you think you have cycles and RAM to burn doesn't mean you use any old BFI algorithm. Programmers should think more not less.
The CE machines had clocks running at several hundred megaHertz, 32-64 megabytes of RAM and FLASH. The machines I'm working with now have only 256kB or 1MB of RAM and four or eight megabytes of FLASH. So how could I possibly be happier?
Every. Cycle. Counts. The fastest instruction takes four cycles, some take dozens (logical shifts). My first big project at this job involved choice between developing a new special-purpose algorithm or tuning a core routine. I compiled that core C routine to assembly and hand-optimised it. Lovingly hand-optimised it. The end result shaved 40% off the execution time. It's not that the compiler was bad, it actually did some very clever things, and I made sure I kept the good bits. Making this program run faster was interesting and challenging because I couldn't just throw a faster CPU or more RAM at the problem and make it go away.
Who does this anymore? Who knows how to do this anymore? Yes, I realise that hand-optimising assembly code for a non-stalling RISC processor is the fast path to insanity, but come on. Optimising isn't always about programming down to the bare metal, sometimes it just means thinking about the problem first. Just because you think you have cycles and RAM to burn doesn't mean you use any old BFI algorithm. Programmers should think more not less.
Labels: hacking
posted by zar' at 21:33
<< Home