Slashdot Mirror
Intel's Dual-core strategy, 75% by end 2006
DigitumDei writes "Intel is moving ahead rapidly with their dual core chips, anticipating 75% of their chip sales to be dual core chips by the end of 2006. With AMD also starting to push their dual core solutions, how long until applications make full use of this. Some applications already make good use of multiple cpu's and of course multiple applications running at the same time instantly benifit. Yet the most cpu intensive applications for the average home machine, games, still mostly do not take advantage of this. When game manufacturers start to release games designed to take advantage of this, are we going to see a huge increase in game complexity/detail or is this benifit going to be less than Intel and AMD would have you believe?"
I hope sol.exe will become dual-core aware soon.
less heat generated. more bang per watt.
It's just that it's called a GPU, sits on a special card, on a special slot and is sold to you regularly about once every six months for an ungodly amount of money.
It would be interesting if games were rewritten to run with the game logic on one core, the graphics on another core and the networking code on a third core of a multicore chip...
Hey. You could even have a mega-multicore chip and do first person shooters with realtime raytracing... each core is responsible for raytracing a small area of the screen. I'm sure that there's a company working on this. I saw a demo video in a computer graphics lecture. I'll have to check my notes.
or is this benifit going to be less
how long will it be before dual core CPUs boost slashdot editor's ability to spell-check?
If their going to be that ambitious with their sales, I hope the are concidering pricing the the chips in a price range that anyone could afford and is willing the pay.
AFAIK memory latency/bandwidth is currently the limiting factor in conmputation speed. Dual core processors will not change this, but make the gap even bigger.
Understanding is a three-edged sword. --Kosh
I don't know if it has been referenced here before, a very interesting and enlightening article : http://www.gotw.ca/publications/concurrency-ddj.ht m
All in all I see that Intel is going down unless they do something quick. And remember Competition is good for the Customer.
Quidquid latine dictum sit, altum videtur
I find this interesting, every machine Apple sells except at the definite low end is dual CPU SMP now, and it's been this way for awhile. Now Intel/AMD seem to be realizing "oh yeah, dual cpus, maybe that's something we should start targeting for the mass market instead of just the high end" (though AMD seems to be pretty comfy with the idea already). I wonder why Apple doesn't seem interested in dual cores though. Intel/AMD seem to be treating multicore tech as their way of getting SMP out of the power-user range, Apple doesn't seem to want to have anything to do with it even though POWER has had multicore ability for a really long time. What's up with this, is there something I'm missing?
"how long until applications make full use of this"
Full use? Probably never. There's always improvements to be made, and multi-threaded programs are a bitch and a half to debug, at least in Linux. Making "full use" of SMP would _generally_ decrease program reliability due to complexity, I would imagine.
But, with an SMP-aware OS (Win2k, WinXP Pro, Linux, etc.), you'll definitely see some multi-tasking benefits immediately. I think the real question is, how will Microsoft adjust their licensing with this new paradigm? Will it be per-core, or per socket/slot?
I'm going to go out on a limb and predict that Longhorn will support 2-way SMP even for the "Home" version.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
The XBox2 and Gamecube are both already known to be using POWER/PowerPC derivatives. Besides which, chip contracts for new consoles are the sort of thing that get worked out an amount of time in advance measured in years, and they're usually not bought from quite the same stock that PC OEMs are buying from. Intel's plans for their mass market "by late 2006" lineup really couldn't have any impact on the console world at all at this moment.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Your statement is true, but I think you missed the point the article poster was trying to get across. Currently games are writeen to use computer resources that way. If the code was written differently for games, they could allocate some of the graphic responsiblities to the 2nd CPU instead of all of it going to the GPU. The 2nd CPU could be used to help the GPU. Allocating more of the now available (2nd CPU) resources to graphics allows more potential in graphics. That's what the article poster wants to see, that game resoure allocation written in the games code be changed to use the 2nd CPU to help enhance graphics in the video game.
I couldn't think of anything witty to say, so...you're stuck with this.
Those bouncing cards STILL leave trails at the end of a game! REFRESH! GAWDAMNIT! REFRESH!!
Note: This sig contains nine S's, nine I's and five O's which... means absolutely nothing.
If you consider a factor of about 1.8 (tops) "huge".
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Check your licensing agreements before you buy one of these dual-core processors. Make sure that your software vendor isn't going to double the price on you.
Oracle and others have announced plans to increase their revenue by charging people for multiple cores in their single processor.
I'm a big tall mofo.
Yes, but since the core of Intel's marketplace consists of people who see a monitor and think it is the computer, this is a barrier that Intel can easily hurdle.
If you had a dual-core system you would have gotten second post too.
I think as long as the hardware becomes established, people will write software for it. From time to time, hardware manufacturers have to push the market in order to get the established standard to jump to the next step.
It's like what Subaru did when they decided to make all their vehicles All Wheel Drive. It was a great technology, but most people at the time just didn't care to pay extra for it. By making it a standard feature, the cost increase is significantly reduced, and provided that the technology is actually something functional, the market should grow to accept it.
"No fair, you changed the outcome by measuring it!" - Professor Hubert J. Farnsworth
As already mentioned games already do make use of the GPU and the CPU so we're fairly used to some mutliprocessor concerns.
To say that most PC games are GPU bound however is a mistake - most games I've come across (and worked on as a games core technology/graphics programmer) are CPU bound - often in the rendering pipeline trying to feed that GPU.
Anyhow games are already becoming dual-core aware. Most if not all multiplayer games make use of threads for there network code - go dual core (or hyperthreading) and you get a performance win. Again most sound systems are multi threaded often with a streaming/decompression thread, again a win on multi core. These days streaming of all manner of data is becoming more important (our game worlds are getting huge) and so again we will be (are) making use of dual core there too.
I personally have spent a fair amount of time performance enhancing our last couple of games (mostly for HT but the same applies to true dual core) to make sure we get the best win we can. For example on dual core machines our games do procedural texture effects on the second core that you just don't get on a single core machine and still get a 20% odd win over single core. I'm sure most software houses take this as seriously as us and do the same. It's very prudent for us to do so - the writings been on the wall about multi processors being the future of top end performance for a while now.
At the end of the day though us games developers have little choice but to embrace multi core architectures and get the best performance we can. We always build software that pushes the hardware to the full extent of it's known limits because that's the nature of the competition.
Just think what the next generation of consoles is going to do for the games programmers general knowledge of concurrent programming techniques. If we're not using all of the cores on our next gen XBox or PS3 then our competition will be and our games will suck in comparison.
I would like to see a more multi-threaded approach to game programming in general, and not all the benefits would necessarily be about performance.
One thing that has bugged me a long time about a lot of games (this has particular relevence to multi-player games, but also single player games to some extent) is the 'game loading' screen. Or rather, the fact that during the 'loading' screen I lose all control of, and ability to interact, with the program.
It has always seemed to me, that it should be possible, with a sufficiently clever multi-threaded approach, to create a game engine where I could, for example, keep chatting with other players while the level/zone/map that I'm transitioning to is being loaded.
Or maybe I really want to just abort the level load and quit the game, because something important in Real Life has just started occuring and I want to just kill the game and move on. With most games, you have to wait until it is done loading before you can then quit out of the game.
In other words, even ignoring performance benefits for a moment, if a game engine is correctly multi-threaded, I could continue to have 'command and control', and chat, functionality while the game engine, in another thread, is loading models and textures.
I believe that we're going to see a performance plateau with processors and raw CPU power for the next 5 years or so.
The only way CPU manufacturers are going to get more *OPS in the future is with many cores, and that's going to require either slower or the same kind of speeds (GHz-wise) as things are today. To get programs to run faster under these circumstances you need some kind of explicitly parallel programming.
We haven't seen the right level of parallelism yet, IMHO. Unix started out with process-level parallelism, but it looks like thread-level paralellism has beaten it, even though it is much more prone to programmer errors.
On the other end of the scale, EPIC architectures like Itanium haven't been able to outcompete older architectures like x86 because the explicitly parallel can be made implicit with clever run-time analysis of code. Intel (and, of course, AMD) are their own worst enemy on the Itanium front. All the CPU h/w prediction etc. removes the benefit of the clever compiler needed for EPIC.
Maybe some kind of middle ground can be reached between the two. Itanium instructions work in triples, and you can effectively view the instruction set as programming three processors working in parallel but with the same register set. This is close (but not quite the same) to what's going to be required to efficiently program multi-core CPUs, beyond simple SMP-style thread-level parallelism. Maybe we need some kind of language which has its concurrency built in (something sort of akin to Concurrent Pascal, but much more up to date), or has no data to share and can be decomposed and analyzed with complete information via lambda calculus. I'm thinking of the functional languages, like ML (consider F# than MS Research is working on), or Haskell.
With a functional language, different cores can work on different branches of the overall graph, and resolve them independentantly, before they're tied together later on.
It's hard to see the kind of mindset changes required for this kind of thinking in software development happening very quickly, though.
We'll see. Interesting times.
Seriously. 75%? What do they think that much power will be used for? Do they dream that everyone will suddenly run out and plunk down $2500 for a machine that can Doom 3 faster than than plutonium doped lightening?
I think all that power will used in the same way it always is. Malcontents will write more sophisticated malware. MS will release more shiny glittery gewgaws that do nothing except open up more security holes and antimalware vendors will write more complex and unwieldy antimalware applications. In the meantime all the corporate suits will demand more cumbersome elaborate corporate apps that are specifically written for dual core systems thereby requiring parallel track applications to be maintained while the old machines the suits abandoned still get cycled through the organization for 3 years. And for the first 12-16 months hardware vendors will experience hardware QA and BIOS screw-up hell as they try to appease the 15 year olds in the focus groups who demand 1337 dual core hawtness!!! It will suck and Intel will make make billions.
- declarative parallelism will always scale better than threads or whatever else
- micro-optimizations will always be faster than declaractive parallelism
Manual parallelism won't scale well from one core to sixty-four cores, but will be faster in static situations like running on one Cell CPU in the PS3 where the configuration is known at design time of the app.This is the same trade-off as manual memory allocation versus garbage collection. Garbage collection is easier and more automatic than manual memory control in C, but if you put enough effort in a C program will be more efficient than a GC-using program.
So the essence of the answer is that declaractive parallelism gives you development speed, but manual parallelism gives you execution speed. You choose what you want.
I have a two CPU machine right now, and I'm very much looking forward to the rumored SMP version of Haskell that uses Software Transactional Memory. That's gonna rock!
Shae Erisson - ScannedInAvian.com
Any aspect of a game may be programmed to scale with the hardware upon which the game is run (eg. graphics get more detailed, framerates improve, physics is more realistic, AI gets smarter)
However, the problem here is that if these improvements to the game are in any way substantial rather than superficial - if they actually affect the gameplay in any way - then users playing the game on a high-end machine will end up playing a substantially different game than users on a low-end machine.
In the case of more detailed graphics, or better framerates, the changes are superficial enough that this does not matter. But for anything deeper - such as AI - the developer has to ask themselves whether it is really desireable for the intelligence of in-game aliens to depend on the nature of the PC the game is run on. Will a low-end PC make the aliens so stupid that the game is substantially easier? Will a high-end PC result in aliens which consistently frustrate the player?
In order to fix this, developers might consider preventing the software from running on systems which are deemed 'too slow', or they may disable features such as 'AI scaling' on systems that are 'too fast' - ironically these desparate measures would of course be in direct opposition to the original intent of making the game scale well across a wide variety of hardware.