Less Software, Less Often

When you read about efforts to increase performance by throwing multiplicity at the problem, a la SLI or dual cores or master/slave Cells, or PPYs, that’s only one side of the story.

Somebody has to pay the piper for increased complexity, and that’s the programmer.

Given that, it’s interesting to note this game developer essentially say, “Two threads are two to three times harder to do.” Harder as in two to three times the time (and thus expense) to do.

That gives a programming company one of five options.

1) They can do the extra work with the people they have. That means much longer periods between finished products, probably too long at least for games. Would you really be willing to wait eight years for Doom 4?

2) They can hire a lot more people to get the extra work done in the same amount of time. That makes the project a lot more expensive, which means they’ll have to charge more and/or sell many more units. As projects get big, they get bureaucratized, which means you get less and less per extra programmer buck. The need to sell more copies (since $150 games is a non-starter) will mean more marketing costs. None of this is good for small companies.

3) You only multithread those items that give you the best bang for the buck to cut down on increased costs. As the abovementioned link states, in the case of Unreal, only certain aspects of the games will be multithreaded. That makes sense, but also limits the theoretical advantages of all this multi stuff.

4) You let somebody else do the dirty work and license their engine. That will certain increase costs to decrease development time, and you have to wonder how different different games are going to be if they’re all using the same engine, and it would be a flexible engine indeed to simulate the World Series and Waterloo.

5) You don’t bother with it at all. I suspect that most programs will take the easy way out. Not power user programs, of course, but most programs that actually run on your computer are really more applets than anything else. To cite a simple example, do you think Microsoft is going to multithread FORMAT.COM? Will it really be worth the bother to multithread WinZip?

The major challenge for a multithreading OS isn’t going to be handling one or two multithreaded megaapps/games; it’s going to be to make sure lots of little single-apps are allocated efficiently between or among CPUs or whatevers, and that they play well together. Not dramatic, just essential.

Software developers will no doubt use all of these options, or blends of two or more. However, the general trend will be towards more complex, expensive-to-make software that will need more and more money to develop and then sell. As more and more units need to be sold to break even, more and more money will have to be found to sell them, which probably means fewer programs will get the heavy push by fewer, bigger companies.

Sounds a little like the music business, now doesn’t it? Actually, it’s a lot worse than the music business. In the music business, at least the costs of recording and distribution drop due to better technology (though the increased need for marketing takes up the slack). Here, the cost of making and marketing the product will go up a lot.

This means on the commercial side that on the whole, the big guys will get more dominant, and the little guys will fall by the wayside. This will even be true on the open source side; if you have X programmers with X amount of time, and the task becomes two to three times as hard, something has to give.

Sorry, but that’s the hidden price you pay for greater complexity (and a big reason why big corporation seem to end up dominating many markets).

Ed

Be the first to comment

Leave a Reply