Coding by ear

September 22, 2015

I just got one of my computer’s fans repaired. It was still working, but noisy like a diesel engine. While I started savoring the relative quietness of my study again, I noticed that I lost something with that repair. I lost a source of information about what my computer is doing.


The fan speed—and noise—varied with the CPU temperature, which in turn varies with its clock speed and workload. The harder the machine works, the noisier it got. At first, you night think (correctly, for that matter) that having a noisy computer is annoying, but I think you can turn that to your advantage while coding.

Having an actual, noisy, grinding fan is an annoyance. But what if we paid attention to the noise our computer makes, use it as a development tool?

It’s easy to forget that a computer is just a machine like any other, and that an intensive computation, in addition of taking time, also consumes power, dissipates heat, and cause wear—especially when disk IO is used intensively. Therefore being aware of what our code does to our computer may make us better coders.

If you don’t benefit from a noisy fan, you can still use the machine’s sensors to keep you informed on what goes on in your box.

  • Sensors. You can use Linux’s sensors command to get a snapshot of your box’s health. The package you need to install varies from a distribution to another, on Debian-like it’s the package lm-sensors. Invoking sensors, maybe within a pretty-printing script, combined with watch (say, watch -n 1 sensors) will let you see what happens.
  • htop, iotop, and nethogs. htop is a prettier, configurable, version of top. It does the essential: processes, process trees, threads, etc. The iotop command needs to be run as root, but will show you what happens with disk IO. nethogs does the same thing for network bandwidth.
  • Conky and other system monitors. A good while ago, I wrote a piece on conky, a simple but highly configurable system monitor. It’s kind of old school (no rounding plasma 3D widgets) but gets the job done. I’ve integrated sensors to it so it also displays the CPU temperature and fan speeds.

* *

Listening to your computer doesn’t replace good software practices (good algorithms, profiling and hunting for hot spots) but complements them. If you hear your HD scratching a whole lot more that it should, you have gained a few bits of information—something unexpected is happening.

* *

In a way, that noisy fan helped me refine my code in more than one occasion. It reminded me that I should be coding for a Pentium III (something I think I advocated before), and that if my program was making my computer noisier, then it probably consumed more resources—CPU, IO, power—than it should have. Keeping my computer quiet forced me to write better, faster, more frugal code.

Keeping an eye on the machine exertion symptoms may help you write better code, especially when scaling is considered. If your program adds 20 degrees to your computer’s internal temperature, how will it scale to service a hundred time more requests?

The CFM-00

June 15, 2010

Parallel computing is the next paradigm shift, everybody knows this, but not everyone is taking the proper action to face it adequately. One thing to do is to read on the subject and force oneself to code using threads and various degrees of parallelism; and that’s pretty easy now that a quad core machine doesn’t cost all that much. But the next step, distributed computing, necessitates, well, more than one machine, and if you have different levels of memories and communication channels, all the better.

So out of a bunch of old x86 PCs, I’ve decided to build my own portable mini-cluster with 8 nodes. Nothing all that impressive, but still plenty of fun to build.

Read the rest of this entry »

Powers of Ten (so to speak)

June 29, 2009

I am not sure if you are old enough to remember the 1977 IBM movie Powers of Ten (trippy version, without narration) [also at the IMDB and wikipedia], but that’s a movie that sure put things in perspective. Thinking in terms of powers of ten helps me sort things out when I am considering a design problem. Thinking of the scale of a problem in terms of physical scale is a good way to assess its true importance for a project. Sometimes the problem is the one to solve, sometimes, it is not. It’s not because a problem is fun, enticing, or challenging, that it has to be solved optimally right away because, in the correct context, considering its true scale, it may not be as important as first thought.


Maybe comparing problems’ scales to powers of ten in the physical realm helps understanding where to put your efforts. So here are the different scales and what I think they should contain:

Read the rest of this entry »