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?
Don't forget that one extra core for compatibility with single-core-only apps!
There are two types of people in the world: those who divide people into two types and those who don't.
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.
Sounds like pure hype. Basically they're saying they have a 2 years technical advantage because they've been working on better multithreading schemes and avoiding deadlocks to put the multi cores at better use. How groundbreaking... Never mind that most game companies obviously have been working on that too but simply don't talk about it. They also make it sound like they invented distcc... which reinforce the impression that they're just trying to impress people and show how high tech they are (not). Almost sounds like a stock increase scheme or something on those lines if you ask me.
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
My current theory is that OpenAL's AL_EXT_VORBIS extension uses a hidden thread and some interaction there lets the game proceed. But that's just a guess. Anyone ever run into something like that?
PHEM - party like it's 1997-2003!
IANAD... But I do dabble a bit and do want to head in that direction professionally (not as a game developer but more towards general applications).
Should I start getting my teeth cut on the concept of multicore programming? Is there enough of an advantage for this doing smalled generalized apps? How does software written with multicore in mind suffer on single core systems?
I've been thinking about this more but currently do not have the proficiency to take this as seriously as the general studies I'm doing currently. Or am I wrong and this is the best time to get me in the habit for what seems to be the future of desktop PCs?
Dedicated Cthulhu Cultist since 4523 BC.
And the technical content is questionable - for example the definitions of multithreading problems are somewhat innaccurate.
It is nice when software is rewritten to take advantage of multiple cores, and imagine that most new games will be designed to do this. For older games, however, Apple has announced that programs using the OpenGL APIs will automatically spawn a process that feeds the GPU, using a second thread. This means, theoretically, some programs could see up to 2X the performance when run on OS X 10.5 and a dual core system, without any changes from the developers.
It's a nice little optimization and hopefully Vista will have something similar (although I heard of such a thing yet).
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/
Your system cannot be aware of the advanced functionality of any device, including CPU's unless:
a) It has drivers
b) It's programmed into the software
c) It comforms to an existing standard in a more efficient way (aka faster at operation X internally, without any different I/O communication to the machine)
I'd rather have drivers at the OS-level than have code-bloat in every app for hundreds of hardware combinations, besides I've been compiling linux kernels specific to my hardware for years, so windows drivers isn't such a stretch.
This is lame, I have been making the argument that FPS != game benchmark. Everyone always says "look dual core FPS is the same as single core, maybe 1 or 2 faster," and they don't even understand why it's 1 or 2 faster (because the few cycles used for AI and physics are out of the way...). It takes VALVE to come out and say it?
Yesterday I blew and made the same statements on kerneltrap. A little unscientific, but should cover the issue nicely.
Support my political activism on Patreon.
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.