The free lunch is over
 

An interesting article about the future of computing, The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software by Herb Sutter is a good read that points out something that I've talked about here before. Concurrency is the future, non-concurrent programs will not benefit from future hardware improvements, and this requires a change in programming paradigm similar to the object orientation paradigm shift.

Well as interesting as it is, it's also something that was predicted many times. I for one can't wait. A change to the general programming paradigm will mean structural change, micro economic reform. Resources will have to be reallocated for retraining, losses in revenue will temporarily occur. Leaving the few who jumped on this in advance to move in and replace those with antiquidated skills, these people will be highly sought after.

Hmm, I wonder how the gaming industry will change the next couple of years. Games are typical single-process single-thread types of applications, and they have traditionally always been using as much computing power as they could.

They'll certainly feel the pressure if 4GHz turns out to be the end point of the processor speed race.

The gaming industry will amongst the first to embrace the change. It has no other choice if you look at the hardware for the next gen consoles.

And there is plenty of potential for parallelism in games. The graphics pipeline can (and has been seens the advent of GPUs) be performed in parallel, but there is also AI, physics, sound, streaming in data (no more loading times between levels), networking, etc. that can all be performed each in it's different thread.

shmoove

Well, I was more thinking about current games. HL2, Doom3 and that pack of games. Aren't they single threaded? They're already toying around with speed requirements that means they have already reached the limit. The problem for the games industry is really that when the roof is hit, it's hit. A game released three years ago today has had sufficient of a speedup that it runs smooth on any non-ancient machine. A game released today will not have had especially much speedup at all in three years, unless it's already written for concurrency. And that's the problem. It won't stop the gains for those that adapt for concurrency today. It will affect those that have released games that have not been written for concurrency today and last year.

Are the current games like HL2 and Doom 3 using Dual Processors if they have them available?

Trends, paradigm shifts, sea changes, and all else that buzzes overhead in the name of progress disturb my simple being. :confused:

Oops I forgot to read another article... no, actually, it's all terribly interesting (that's the problem)! ;)

Oh, OK. I was thinking about new games that would be designed from the get-go with multithreading in mind.

shmoove

Well you'd expect them to work just as a single thread and not show much speed increase as say the same game that had been multi-threaded.

But I have no idea, something I'd like to read up on though.

But just imagine how great it would be to be making a multithreaded game (I know I need a life). The modularity of it. It'd take object oriented designs to another level entirely. Perhaps we could see room for an even more object oriented language to take center stage. Perhaps even D might see increased use. I plan to port my game engine to D once it reaches the first release version.

Well, the tendency we've seen for inherently concurrent languages so far is rather the opposite - APL, K, J, Linda are not object oriented at all. However, SmallTalk, C-Linda, Java, threaded C/C++ and other not inherently concurrent but strongly threaded languages have proven quite good at it lately. But then you must remember that threading has less to do with the language and more with the operative system.

True, but I'm talking more of the actual design to the program. When it is multithreaded it creates a more modular view of the program, well at least to me it does. You may not have much control over the actual threading (although you could if you wanted I'm sure) but you will have to create the processes at some stage at the very least.