Fri, 29 Apr 2005 00:00:00 UT

Speed Fetish

I'm a speed fetishist just as much as the assembly, C, and OCaml addicts, but I take a longer term approach.
A good algorithm in a shell script can easily be faster than a bad algorithm written in assembly, so I value Speed of Change far above speed of execution. Execution optimizations are great, as long as they don't require me to sacrifice speed of change.
You can optimize a given algorithm only so far, after which it is time to change your abstraction, your algorithm, or maybe the whole solution. No matter what you've got, you can be sure there's a better solution. If you can restructure your entire application in an hour, you can get a lot closer to the unreachable perfect solution than if it takes you a week to explore a new idea.

I got started on this discussion because OCaml sacrifices speed of change and correctness to get speed of execution.
Integers in OCaml are different sizes depending on whether you have a 32 bit or 64 bit cpu, and they silently overflow.
Here's a quote from a discussion on lambda-the-ultimate.org:

The language has fast, unchecked integers because people demand performance (as evidenced by the other thread about C-class performance). The performance is one factor which drives its acceptance for some real applications. But then we need to start retrofitting solutions to the problems which were created by the pursuit of performance.

In other computing news, Chip-Scale Refrigerators Cool Bulk Objects. After the recent discussion I had with Bastiaan Zapf, I wonder if this is the breakthrough that makes desktop Josephson Junctions worthwhile? Too bad CiteSeer is down, I can't search for information on electron tunnelling refrigeration. I wish CiteSeer would upgrade. Maybe they allow the whole database to be downloaded?

Today's image is from the freestyle unicycling gallery of Yoggi Toulouse.