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?
So their "new direction" is "we're going to use them?"
Amazing.
For the closest shave! Er... fastest app!
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
Why is this Valve advertisment posted on Slashdot?
They say nothing revolutionary here, it's just "we did the most obvious thing we could think of, btw you should buy engine licenses from us".
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. Games are not easily parallellisable. For now, it's sufficient to split off some low hanging fruit onto extra cores and get a decent CPU utilization, but what happens in a few years? Intel claims that they will have 80 core CPUs by then so it's probably not unreasonable to think that the next "next gen" consoles will have at least 50 hardware threads or so.
So what the hell do we do? Are our current tools (C/C++) really sufficent for programming non-easily-parallellisible applications like game engines when we have to scale to the high tens, and low hundreds of threads? I don't think so. Just like using assembly exclusively to program a next gen console engine is theoretically possible, but practically impossible, using C++ to program massively multithreaded game engines will simply not be feasible.
So what the hell do we do?
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. But then again, the highly conservative estimate of 2x worse performance compared to C++ (it's usually better) still means that it'll win out with enough threads (a hypothetical C++ program which simply isn't feasible to write is slower than an actual and correct Haskell program).
Even so. We're pretty much screwed. It seems like the industry is moving far too slow on this. There is a coming crisis here, and we don't really have a solution (except higher development costs, more developer, more bugs, and less profit).
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.
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?
:)
Remember that today's GPUs have way more transistors for logic than today's CPUs (because they can easily do so much more in parallel). If AMD started supporting GPU instructions (the low-level stuff beneath 3D API calls -- mostly FP vector ops), it wouldn't mean squat unless they managed to add all those dozens of execution units for the ops as well. ATI and Nvidia are constantly pushing (TSMC/UMC) manufacturing to the limits to have even more shader engines in their GPU chips -- AMD hardly has the transistor budget to add even one of those cores into their single-core Athlon chips.
And your solution would instantly make most games bandwidth-limited -- today's video cards offer faster memory on a twice wider bus, dedicated to the GPU only.
Sheesh, the whole point of 3D accelerator chips from the friggin' ViRGE onwards was to add more horsepower to augment the CPU. Why the heck try to squeeze all that back into the CPU? Add more plain jane CPU cores or L2 cache instead, and keep graphics where it belongs...
That said, I happily agree with the rest of your post