Slashdot Mirror


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.'"

2 of 80 comments (clear)

  1. Debugging multithreaded code by Coryoth · · Score: 4, Informative

    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 (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, and for C++: C++CSP. 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.

  2. multi-core and GPU/CPU integration by EricBoyd · · Score: 4, Informative

    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 which is my prediction for how the whole field is going to evolve over the next 14 years.

    --
    augment your senses: http://sensebridge.net/