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.'"
I remember reading of all kinds of bugs in games running on dual-core processors in Windows. Something to do with the OS providing different amount of power to the two cores. Has that been sorted out, or will Valve be compensating in the game engine code?
With Videos! (on the 4th page.)
Demented But Determined.
I realize this was brought up in the story, but I really do think that when AMD bought ATI, they were looking forward at stuff like this. If AMD started adding ATI GPU instructions to their cores, and you get 4 of them on one slot along with the memory controller, what kind of frame rates and graphical shenanigans will happen then?
Of course, the problem is that my AMD 64 3200 will do DirectX 8 with my old GeForce, and will do DirectX 10 if I buy the new ATI card after Vista ships since its the video card handling that. But if I buy the new AMD multicore CPU w/ GPU instructions, will I have to upgrade my processor rather than my video card to get new features? And if I do, what will the processor price points be since new Intel/AMD extreme chips cost $1000 at launch, and the bleeding edge graphics cards cost $500?
As of right now, I get a big boost in game performance if I just upgrade my old video card and buy a new one.
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.
Craft Beer Programming T-shirts
I found this paragraph from the conclusion really interesting:
e rs_in_20.html
which is my prediction for how the whole field is going to evolve over the next 14 years.
"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/comput
augment your senses: http://sensebridge.net/
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.
Too bad as I'll never buy another Valve game because of Steam.
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
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.
Yep. Valve finally hired a systems programmer, and now they can do threading. This is almost as revolutionary as hiring someone with a background in AI to work on AI, rather than hiring a graphics programmer to do AI.
Yes, this method is an obvious way to get some benefit from a small number of extra hardware threads. But it is *not* future proof. This approach may give good CPU utilization up to perhaps 10-20 threads, but after that it will start to take a big dive.
While they are obviously not doing anything that supercomputer programmers didn't invent 30 years ago, they are leading their industry into the future, err, present. Though the article details are pretty weak, its clear that they've already gone beyond the module-level threading (sound, AI, graphics), to something that sounds more like work queues. If done right, those can get you to hundreds of threads as seen on early supercomputers, although it doesn't sound like Valve is dealing with cache-sharing problems yet, which could cause problems far sooner. I'm hoping hardware + language extensions will help mitigate that somewhat, at least on the read-sharing side.
Personally, my bet is on languages like Haskell. Purely functional programming makes multithreading easy, and for the imperative bits it has transactional memory (no locks, no deadlocks, and finally composability even with multithreading). Haskell itself may be too slow, so we may need to find a non-lazy version (laziness is basically the biggest performance problem Haskell has) for it to be practical.
I think OCaml has a lot better chance of becoming mainstream than Haskell. For one thing, I know of programs written in OCaml that aren't written by members of the PL community. For Haskell, outside of compilers and libraries, the only thing I can think of is Darcs, and that project is having all sorts of issues with determining and fixing performance problems (I love darcs though!). I'm not sure a pure-lazy language will ever map well to a soft-realtime media app such as a game. Also, when you really need delayed evaluation (i.e. laziness), ML derivatives have closures and higher-order functions which allow you to implement it easily enough.