Repeating Oneself . . .

To a large extent, I will be repeating some things I’ve said in the past, but some things bear repeating.

In one sentence, over the next number of years, the true pace of improvement will be determined not by silicon, but by software.

CPU manufacturers no longer can make everything run faster just by juicing the clock early and often, so they have to pull other, less guaranteed tricks out of their bag to step up the pace.

64-bit processing is one of them. Multicores are another. However, unlike pumping up the GHz, these improvements won’t do squat for any program not written (or rewritten) to take advantage of them.

Even if you do program or reprogram for them, the improvements are going to be hit-or-miss simply because many computing tasks can’t be helped by making the highway wider or putting more cars on it.

Finally, reprogramming can be a very, very expensive task. This isn’t so much the case for 64-bit, but when you have different processors doing different things, you do have to program coordination in to keep everything synchronized, which creates a whole new universe of errors and bugs.

Until the Age of Speed ended, programmers had an easy task of it. The ever-increasing speed of the CPUs allowed app and game writers to get away with a lot of mediocre code from a lot of mediocre (but cheaper) programmers. Have a new feature, CPUers? Give us a checkbox in the compiler if you expect us to use it.

Those days are over. Now the CPUers need two to tango for their latest and greatest to work, and it’s quite arguable that the programmers are the ones who now have to lead, and they understandably feel like they’ve been left holding the bag.

And frankly, they pretty much don’t want to. Before you condemn too much, if you had to do five times the work and expense to get a 20% improvement, between the extra code, and the retraining, and the washing out of those programmers who can’t hack the greater complexity of the task and paying those who can more, you might not be too enthused, either.

It’s a lot easier for two CPU companies to add extra cores than for armies of app writers to add the extra programming to use them.

I’m not going to suggest who is more at fault here, in the end, it doesn’t matter. If the CPU is evolving from one big centralized brain to swarms of bright bees, that means a revolution in programming. That is going to take a long, long time to fight, probably a decade or more, because people change a lot more slowly than silicon, and unlike people, silicon can’t resist change.

Ed


Be the first to comment

Leave a Reply