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 |