Real Time != Real Fast

Since I've been involved in real time programming and the Real Time Specification for Java (JSR1) work, I've had a lot of people ask me about where real time can be used. There's more than a little confusion: many folks who've asked for "real time" actually want "real fast" (throughput computing). In real time computing, meeting a very precise deadline is of paramount importance. In throughput computing, the goal is to get as much done as possible as soon as possible.

I hate to use sports analogies, but this a a situation where one works well. Consider baseball: how fast you swing the bat is less important than that the bat be in the right place at the right time in order to connect with the ball. Real time programming is kind of like being a batter where the pitcher throws the balls continuously. And instead of a catcher behind the home plane you have a sleeping troll who will eat you if a ball gets through and hits him.

A good way to think of throughput computing is the old Sharpen the Axe principle:

If I had eight hours to chop down a tree, I'd spend six sharpening my axe. -- Abraham Lincoln

Many activities done in standard programming can be thought of this way: they're things you do now that are not directly useful, but later on they make life better. This is everything from JIT compilers and garbage collectors down to simple things like hash tables. (Hash tables? Yes! That "re-hashing" phase that happens when tables overflow adds a bump of cpu cost; hashtables that chain instead of rehashing have non-linear [unpredictable] lookup costs).

The number of developers who truly need to do realtime is very small. But the stuff they do affects us all. Planes, trains and automobiles: all need realtime.

June 21, 2005