Valve's New Direction On Multicore Processors

illeism writes "Ars Technica has a good piece on Valve's about face on multithread and multicore application in programming. From the article: '...we were treated to an unveiling of the company's new programming strategy, which has been completely realigned around supporting multiple CPU cores. Valve is planning on more than just supporting them. It wants to make the absolute maximum use of the extra power to deliver more than just extra frames per second, but also a more immersive gaming experience.'"

A good suppliment article

[Dr. Eggman]

With Videos! [bit-tech.net] (on the 4th page.)

Re:So have the Win multicore bugs been worked out?

[Ford Prefect]

I've had no problems at all with the original Half-Life, and its sequel, on a dual-core machine [hylobatidae.org].

From a modding point of view, the Source map compilation tools are fully SMP-aware - so I guess someone at Valve knows about multithreaded programming. Seeing both processors pegged at 100% is great, as is hearing the whooshing noise from my laptop's fans. No belching of flames quite yet, fortunately.

(Actually, the compilation tools will scale up to running in a distributed manner - apparently at Valve, even the receptionist's PC contributes processor time. But the necessary glue code isn't available for us modders, alas.)

Debugging multithreaded code

[Coryoth]

Debugging multithreaded code can be relatively easy, you just have to start off on the right foot. The best way to do that is to leave behind older concurrency models like monitors with mutexes, which the inventor of that model rejected back in the 80s and go with more recent concurrency models like CSP [usingcsp.com] (the newer way to do concurrency from the man who brought you monitors). From a more modern perspective like CSP reasoning about concurrency is a lot easier, and hence debugging becomes much simpler. In fact tere are model checking tools that can verify lack of deadlocks etc. The downside is that its much easier if you have a language that supports the model, or get an addon library to do it for you. You can get a CSP add-ons for Java: JCSP [kent.ac.uk], and for C++: C++CSP [twistedsquare.com]. Alternatively languages like Eiffel, Erlang, Occam, and Oz, offer more of hat you need out of the box - concurrent programming with those languages is easy to get right. Changing languages is, of course, not an option for most people.

Re:So have the Win multicore bugs been worked out?

[Apocalypse111]

For a while, if you played Planetside with a dual-core machine it essentially gave you a speedhack. It didn't affect your rate of fire, but it did affect your rate of movement, and how quickly your COF bloom came back down. While in the lightest armor available, and with the speed implant installed and enabled, it was possible to run almost as fast as a Mosquito (the fastest aircraft available) on afterburners. In a tank you were almost untouchable, and a Galaxy (large air transport craft capable of carrying 12 people including the pilot) could get you and your squad to your target faster than the enemy could respond. It was nuts, but fortunatly not much abused as those caught doing it were frequently reported.

multi-core and GPU/CPU integration

[EricBoyd]

I found this paragraph from the conclusion really interesting:

"Newell even talked about a trend he sees happening in the future that he calls the "Post-GPU Era." He predicts that as more and more cores appear on single chip dies, companies like Intel and AMD will add more CPU instructions that perform tasks normally handled by the GPU. This could lead to a point where coders and gamers no longer have to worry if a certain game is "CPU-bound" or "GPU-bound," only that the more cores they have available the better the game will perform. Newell says that if it does, his company is in an even better position to take advantage of it."

This is almost certainly why AMD has bought out ATI - they see that the future is about integrating everything on the motherboard into one IC, and AMD wants the CPU to be that point of integration. For more, see:

Computers in 2020
http://digitalcrusader.ca/archives/2006/02/compute rs_in_20.html [digitalcrusader.ca] which is my prediction for how the whole field is going to evolve over the next 14 years.

Re:OS X Leopard and OpenGL

[99BottlesOfBeerInMyF]

Ati and Nvidia's drivers are already multithreaded on windows but there is only a 10% improvement at best... Rendering frames to the screen is inherently serial so you can't make it much faster with more cores.

We're not talking about the drivers, per se. Many the libraries used by OpenGL programs and some of the OS interactions will be spawned as a second "feeder" process that does nothing but send data to the graphics card/drivers. This means programs who are CPU bound and single threaded, can offload one big task to the second processor without any work from the developers or even recompiling. Theoretically, the perfect storm would be a process where half the work is feeding the GPU and the bottleneck to the GPU is at least half as wide as the CPU bottleneck... resulting in twice the performance. This will never happen, of course, and I don't expect much benefit from this optimization in general, but it is still kinda neat and might be useful in some instances.

dual vs. single + gpu

[GoatVomit]

If you are on a budget and want to play games you'll probably get more bang for the buck with a single core proc and a better gpu than with the same amount of cash spent on dual core + slower gpu. I've been waiting for this to change for a while but so far it's been more marketing than anything else. I ended up moving the dual core proc to a linux box and single core to windows after a few weeks of testing. Naturally windows chugs more after a game and isn't as responsive but while playing it was hard to notice any tangible difference. With all the talk about the future the present seems forgotten.