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.
One has to wonder if this is going to provide Intel with a competitive edge against Sony's Cell processor in the gaming front...
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?
Wasn't Quake 3 supposed to be able to take advantage of SMP?
Keyboard not found.
Press F1 to continue.
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.
are we going to see a huge increase in game complexity/detail
complexity? Isn't multi-core programming pretty much the same as multi-processor programming?
detail? If this helps greatly for performance and it's relatively cheap (it's on affordable consumer chips) then why not a processor with 3 cores, or 5?
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
Once multi-core chips start getting into home computers, the game developers will have a good justification for writing thread-awesome programs.
So I guess the answer to the question is, "pretty soon."
My other processor is big-endian.
gamers and gaming companies have been a massive driving force in the use of any such new technology ... I expect that gaming outfits are already salivating over the possibility of next years vpu's and dual core cpu's ... but remember there is a delay gap on the uptake of the new tech by the commoners ( for want of a better term ), so it will be a fine line for the companiers to invest time and resources into programming for a new boxen, if the vast majority are going to be on their vanilla boxen through 2007 ...
Question Authority before IT questions You
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?
... and more everwhere else. Games continue to get most of their good stuff from the GPU, not the CPU. It aint that the CPU isn't important, but it's not going to make a huge difference all by itself.
What I hope to see, but don't expect, is better prioritization of CPU requests. If you have something high-priority going on, like a full screen video game, recording a movie or ripping a CD, I'd like to see the antivirus and other maintenance tasks handled by the other core, or even put on hold. My personal experience is that this stuff can sometimes be set up to some extent, but it's overall kind of crappy and labor intensive.
But this really isn't intel's fault. MS and the app vendors need to take the blame. So, the question is: do other OSs handle this better for consumer products?
TW
"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.
Intel and AMD are aiming for databases.
Is it absolutely necessary to have a sig. ?
A little off topic, but anybody find it interesting that all the next generation consoles will use IBM processing power? Considering the number of consoles sold compared to PCs, this has got to piss both Intel and AMD off...
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.
For example on the Intel HT processors, all I have to do is write my applications to use multiple threads for operations that are CPU intensive and voila! I have almost doubled the speed of my app. Otherwise, a single thread app will only use one of the cores.
Often, it's almost trivial to write an app as a multi-threaded app. The only difficult part is when a the problem your application is solving does not lend itself well to paralellization. So sequential problems don't really benefit from it.
However, this is almost always -something- that can be done in paralell. Even if the problem the app is solving is highly sequential, if you need to read the disk or anything, you can always implement look-ahead and caching code that runs in a different thread. Or whatever. Because it's rare you will just cruch numbers and not display it, require data, or send it across a network. Usually, the GUI itself will have it's own thread and benefit from a dual-core processor
Intel is pushing dual cores? Sony's Cell has [i]nine[/i] cores!
Oh, come on, it's just dual, it's just a marketing trick. Speed has been increasing in a logarithmic manner for years on end, and now we're gonna stand still at the word "Dual"? If intel/amd devise a way within reason to logarithmically increase the number of cores in a CPU (which I strongly doubt), that'll be a breakthrough. But for now - it's just a way to keep prices high without inventing anything at all. WOW!
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.
1. game complexity has hardly to do anything with the CPU. That is if you're not John Carmack and let the lightning be done on the CPU (not a wise thing to do). 2. more "irrelevant" stuff wil be pushed on the CPU from the GPU and thus making more use of the GPU => higher detail/complexity. 3. more realistic physics (ragdoll), better AI, more complex sound effects (5.1?). 4. [ot?] Microsoft will only charge one Windows license on the actual CPU => 1 CPU with n cores == 1 license. IBM and others (I think also Sun) will charge per core => 1 AMD with 2 cores == 2 OS licenses.
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.
This problem has already been solved by OpenGL Performer
Applications, even 'games', written using Performer, will immediately benefit from multiple CPUs.
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.
If only a demo were the same thing as a shipping product...
If this were coupled with a multi-cored GPU, think of the benefits Gamers would reap. Of course, Longhorn might require you to have both those processor cores, and one more video card, SLI'ed in to handle the vole-bloat...
Windows has detected an undetectable error.
I'm not convinced that dual-cores are the answer to the problem both Intel and AMD are now having scaling up CPU performance.
Using dual-core for games for example will certainly allow developers to make some enhancement to their games by parallelising non-dependant parts of their engine e.g. split A.I. and physics up, but at the end of the day once you've broken the game down to these parts you're going to be limited by processor speed again. Things can only be sub-divided into smaller tasks so much, once that limit is hit you again are reliant on faster clock speeds to do more.
I believe dual-cores are a distraction while the fundamental problem of reducing transistor leakage is addressed.
I am going to wait for at least quad core 64bit processors ;)
The only 'games' i play on my computer are chess engines. What about those? Will they benefit from dual-core?
A lot of pieces have to be in place first. Multi-core cpus have exist first. That's just starting to happen. You have to have decent OS and api support for multiprocessing that exploits it rather than putting in locks to make it seem single threaded which slows things down considerably. Then you get the apps to start using it. Big learning curve on that last bit. Pretty spectacular program crashes when it's done wrong. Lot's of gibbage, which make debugging from a core dump challenging.
A lot of posts have quite rightly pointed out that the GPU is currently how games use a "pseudo" dual core. But it seems that what games could be doing now is harnessing the potential of dual core not for graphics, but for game enhancement i.e. better physics and true AI implementations. Realism in games has to go beyond tarting up the graphics.
"Consensus" in science is _always_ a political construct.
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.
The average system is already running a number of different processes at once. Even if most individual applications aren't multithreaded, a dual-core will help not only make the system technically faster but also help hugely on the response of the system (which is often a far more important factor for the 'feel' of how fast a system is as the user experiences it) whenever process are running in the background.
While one might ask whether it makes much useful difference to the 'average' home user, one might ask the same about say 4ghz vs 2ghz - for most Microsoft Word users this makes little difference in any case. However, for most users who really make use of CPU-power in whatever form, the dual-core will indeed make a difference even without multi-threaded applications, and it won't take long for most applications where it matters to become multi-threaded, as its really not that hard to make most cpu-intensive tasks multi-threaded and thus further improve things.
I for one am looking forward to buying my first dual-CPU, dual-core system (i.e. 4x the power) once the chips have arrived and reached reasonable price levels, and I'm sure that power won't be going to waste.
How would be having two memory controllers bad? Actually, it may be great - you won't have a central bus to saturate, you'll have two.
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.
AMD will be releasing Quad Core chips as early as 2007 according to Arstechnica. Where does that leave Dual Core?
0 99 .html
http://arstechnica.com/news.ars/post/20040813-4
my software is always asking for more memory.
webdevelopers design webpages that noone on dialup can view. pushing the percieved need for broadband.
what a dual core cpu needs is a magic converter piece that enables 32bit code to fully utilize 64bit processing. THEN everyone will want one, and software can creep into 64bit computing at it's own pace.
i remeber needing a 16bit FATed partition for the running of 16 bit programs under 98 but that was only 5 years ago.
hey amd e-me for some architecture ideas.
"He's a real midnight golfer"
anticipating 75% of their chip sales to be dual core chips by the end of 2006
global warming expected to increase by 75% by the end of 2006
hack a day
Dual core is a godsend!
As anyone who works with number crunching apps will tell you, having two cores seriously improves your work quality.
Not because number crunchings apps are taking advantage of dual cores.
It's becasue now I can set one core to work on those wicked hard numerical calculations while I kick back and watch movies and play music for a few hours. Bliss!
Nevertheless it would be nice if there was an easier way to make apps use multiple cores. I'd love to be able speed up my crunching by getting a program to use both cores, intuitavely, but I don't expect this to happen any time soon. Surely there has to be easier ways of making apps thread compliant?
May the Maths Be with you!
I would think so! All the "big" chess computers (Deep Blue, etc...) have just been massively parallel systems, and chess is one of those things that people have been coding and refining for years. I'm not much of a chess player myself-- computers have been kicking my ass since the 1MHz era, but it appears that multiprocessor chess software is already available for end-users:
Deep Junior 9 and Deep Shredder 9 support multiple processors, and should have no trouble on a multicore system.
Each core doubles how many moves it can evaluate in a given time-- and searching possible moves is primarily how chess algorithms work.
Plus... Shredder renders a fancy 3D glass chess set for you, making sure your GPU doesn't get lonely with nothing to do.
...shouldn't there be a big advantage running a uniprocessor game on a dual-core CPU? Send all other threads to the other core (I assume each one must be woken up to see if it wants to do anything quite regularly). I seem to remember the Linux kernel does context switches 1000 times a second or there abouts. Say you have 3-4 threads (AI, network, graphics, sound) should still leave you able to check those at 250fps...
Kjella
Live today, because you never know what tomorrow brings
Intel and AMD have hit the clockspeed Wall. How then do they market new product?
Instead of growing up they grow out and market the heck out of dual core technology to hype up new consumer sales. Neither gives a flip if consumer software takes any advantage of dual core. It's there for "new and improved" because "new and improved" is marketable.
If dual core were sooooo wonderful for consumers, then every enthusiast desktop would already be a dual CPU rig. My 6lb laptop runs Doom3 and Farcry very well. I have a hard time justifying buying a noisy, hot, power hungry desktop just for gaming performance gains I may not even notice.
And if the Cell Processor lives up to its hype, Intel and AMD are obsolete anyway.
That said dual core is huge for the data center. More performance per watt to allow greater cpu densitity per square foot of raised floor space and every amp.
Games do comsume a lot of cpu but are not typically multithreaded. Eventually, games will be multithreaded, as we see more multi-core systems out there. As far as gaming, AMD sees that a single core solution is still the best for gaming. Thus, they plan to market the single core Athlon 64 FX to high end gamers even after the introduction of the dual-core Athlon 64.
As for the effect of the memory controllers, time and real-world use will tell. Unlike AMD, Intel don't have to change the CPU design every time a new memory type comes out. Swings and roundabouts.
More importantly, how long will it be before dual core CPUs boost slashdot editor's ability to dupe-check before posting?
I would expect to see at least some benefit from the kernel and other OS processes running on one core and an app or game, even if single threaded, running on the other. Now it certainly won't be a twofold improvement but I would expect at least 20%. I have seen this kind of improvement when running a heavily used database on a dual processor machine.
When dual-core procs become the norm, Oracle will wonder why everybody stopped buying their software, and will adjust their pricing accordingly. Oracle has made a science out of accurately determining what price the market is actually willing to bear, just a smidgeon short of the market telling them to "F--- Off" and that's what their pricing structure will be. Oracle keeps the "riff raff" out of their customer base that way, and only wishes to deal with the serious players who must have their database when no others will do. It's kinda like the world of business jet aircraft... hideously expensive, but there is still enough market demand out there such that the vendors are barely able to keep up with it.
"No, because most games depend more on the gpu rather than the CPU. The cpu is left to do tasks such as opponent AI, physics, etc, stuff that the dedicated hardware on the graphics card can't do."
It's funny that we read the phrase "complexity/detail" applied to games and automatically assume it must refer to graphics...
Stuff like complex AI or detailed physics certainly may benefit here.
Even if the app you're running isn't multithreaded you'll see some benefit from dual processor. After all, you're always running the OS as well as your application, including your wireless drivers and what have you. If nothing else you're saving a context switch by giving the application its own processor.
selling this year, instead of 2 years from now
PHP is the solution of choice for relaying mysql errors to web users.
Aww, the AMD fanboi got his po wittle feelings hurt by Intel's product plans.
When I was specing out a PC for my mother in law, she pointed at the case and said "I don't think I'll need that part". She wanted just the monitor, keyboard and mouse.
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.
Nearly every user will see a small increase in gaming performance from the start (assuming you don't downgrade in frequency). As previousely mentioned, there are applications that run in the background of games. The second core could take on the background application while the first is dedicated to the game.
Now, not everyone will have something in the background sucking up a good deal of your CPU while you're playing. In fact, anyone who's watching their performance will close all possible background applications before gaming. However, with a multicore CPU you wouldn't have to bother doing this. I think the convenience is worth the $80 price difference (Intel).
Also, if Intel comes through will this 75% deal (and AMD follows suite) then the dev's will have no choice but to take advantage of this technology. An expected factor of 1.8 (previousely mentioned) would be a huge increase in CPU power. This could lead to better physics/sounds/AI etc. Ever try cranking the physics engine in HL2 in a game with a lot of NPC's?
Games don't drive hardware unless you are the CEO of Alienware or some hole in the wall computer shop that builds gaming systems. What will drive these CPUs to larger market share is virtualization. Microsoft's acquisition of Connectix alludes to that. I expect that they will take the virtualization technology and incorporate it into some vuture version of Windows in order to provide much more robust system recovery. Hard drive space is cheap, RAM is still relatively cheap and if Dual cores get cheaper and faster, the home user will probably be able to transparently take advantage of virtualization. That is what will drive the dual core market. That's the only reason I am considering a dual Opteron solution for the home server. (Expect to see home servers a commonplace fixture in the future. They will be called something else, but they will be home servers)
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Where are AMD's dual core chips? Sure as hell can't buy them today...
I had a vendor's SE tell me that AMD's dual core chips are "practically sitting in boxes at a warehouse" so that the day Intel starts shipping developer samples they can start shipping actual products to end users immediately, giving them a huge head start in terms of marketing and, if you believe they've already been manufacturing them, the ability to discount them faster than Intel can.
I think that's a strange strategy, but I was also told that AMD has gotten burned by being too far ahead of the curve before (Athlon?); apparently having Intel do it, too, lends credibility and mindshare to technologies, enabling greater acceptance of an AMD solution.
Of course this is conspiracy theory and marketing speak from an SE, so who knows, but it's not completely implausable. Having a huge supply of readily-MB-compatible dual core CPUs you can start shipping immediately as your competitor's product is just beginning production (and requires new mainboard designs to boot) could allow you to steal their marketing hoopla for your _available_ product.
Ciao
PS Yep, I know most gamers will fork out the money but no-way will gamers give that 75% figure. You need ordinary folks buying in to get 75% sales figures.
I kind of doubt this story since neither Intel nor AMD have ever done a very good job of keeping their product plans secret. If AMD even had samples out there, we'd know about it.
Who will spend the extra money on dual core CPUs if there are "no" games taking advantage of them ?
Who will spend money developing games for dual core CPUs if there "no" dual core machines ?
Well, that is one approach to getting rid of loading screens, yes, and I've seen that used in some games.
But, every game at some point has a load screen, whether it is when you initially enter to world, or use some sort of 'rapid-travel' system, like teleportation, portals, shuttles/boats, etc. Or, in FPS games, when you just finish one map, and everyone goes on to the next map in the cycle.
My point is, when you have the inevitable load screen up, because at some point you have to, at least let the players chat, quit, and do other meaningful interactions with the program while it loads.
Another example of things to do while the map loads: In the game Wolfenstein: Enemy Territory, about the first thing you have to do when you start playing a map, is select what team you want to be on, what class you want to play (e.g. medic, field ops, soldier, covert ops, engineer), and sometimes, what spawn point you want to appear at in the game.
It would be very cool if I could select those options while the map is still loading, instead of being forced to wait until it has completely finished loading. Since my computer is a little slower than some people's, and some ET servers have a *very* short 'warm-up' period between matches, I very often find myself loading with like 2 seconds until the game starts. Which means that by the time I've selected team/class/spawnpoint, I've missed the first spawn of the game. (And many a game is won or lost in the first 30 seconds, sadly). Being able to interact with the game, and make these choices while I wait for the map to load, would be good user-interface design, enabled by multi-threaded techniques (that is, the game engine is loading the map/zone in one thread, and doing UI/chat/control stuff in another thread).
Laugh, it's funny.
Or groan if it's not.
Physics - different ball game. In the future we really will need dedicated physics hardware...if even for geek amusement.
- 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
Even more importantly, it will allow for more efficient duping. One core can be working on posting a story, while the other core posts the exact same story. This way there wouldn't be that irritating lag while you wait for the dupe to be posting.
Well, we've had a lot of engines come out recently such as the new Half-Life, Doom III, etc.
Games are usually built on such engines because the licensing fees greatly reduce costs over writing your own engine. It seems to me that there will be no main-stream use of dual-core processing in gaming until the engines start taking advantage of it.
Some games, such as WoW, where they build their own engine could begin taking advantage of this sooner but we will not see this in mainstream gaming until the next set of engines come out. Then we're going to have to take a look at whether they run dual-core or, likely, those new fangled cell processors.
I'd say we have some time to wait.
Having multiple processors or multiple processor cores provides more of an advantage in a number of ways, than just having a single processor that is twice as fast. You may notice most animals have two eyes. The reason is that when one eye gets poked out by a sharp stick, the animal can still see. Similarly, when a thread loops and tries to monopolize your entire processor, having a second one means your machine is still responsive. There are performance hits involved in multithreading, but the advantages of more scalable code, more redundancy and reliability, and more ability for parallel operations make moving to multiple processors and cores a more significant improvement, IMHO, than doubling the speed of a processor.
Games will most definitely benefit immediately from dual-"The Core" technology. Until now, programmers could only have either the theatrical OR the director's cut of "The Core" loaded into the processor at any one time. It is well known that all games use the Plot_Ideas_From_The_Core( _crapin, _crapout) library built into the x86 architecture. Therefore all games in existence suck, save the clever !_crapout work-around developed by John Carmack. Enabling simultaneous access to both versions of "The Core" via the theatrical/directors context switch will enable real-time mixing of various _crapout plot nuances, which if done in a random enough way, may actually make the story of "The Core" make a little sense.
The is some concern about upgradability, however. As many may fear, "The Core 2" is probably in production at some secret subterranean (sic) location. When it is released, game publishers will quickly migrate to dual-"The Core 1-2" technology, enabling a whole new era of Games That Suck, in ways we can only imagine. Therefore there is considerable noise in the community for re-writable "The Core"s. Intel is hesitant to produce such a chip, as enthusiasts are certain to defeat the "The Core"-DRM and overwrite it with whatever they please. I for one think lowly of such scofflaws, as supplanting "The Core" technology with anything else robs oscar-collecting Hillary Swank of the recognition she so richly deserves for starring in this gem of a film. It is rumored an unlicensed open-source dual-"The Matrix 1-2" port is in the works, which results in an instant 7-8 order-of-magnitude improvement in game quality across the board, without any tweaking! Hah, fat chance! IMHO, nothing beats an infinite-heat-capacity drilling sausage boring into a super-colossal mantle-geode plot twist.
On second thought, maybe anything does.
Well,
I've seen methods and libraries that allow you to sort of 'ghetto-multithread' without actually using system thread facilities to accomplish it.
But ultimately, it comes down to something that is conceptually similar to multi-threading. That is, multiple semi-independent paths of execution that appear to happen simultaneously.
Games will most definitely benefit immediately from dual-"The Core" technology. Until now, programmers could only have either the theatrical OR the director's cut of "The Core" loaded into the processor at any one time. It is well known that all games use the Plot_Ideas_From_The_Core( _crapin, _crapout) library built into the x86 architecture. Therefore all games in existence suck, save the ciever !crapout work-around developed by John Carmack. Enabling simultaneous access to both versions of "The Core" via the theatrical/directors context switch will enable real-time mixing of various _crapout plot nuances, which if done in a random enough way, may actually make the story of "The Core" make a little sense.
The is some concern about upgradability, however. As many may fear, "The Core 2" is probably in production at some secret subterranean (sic) location. When it is released, game publishers will quickly migrate to dual-"The Core 1-2" technology, enabling a whole new era of Games That Suck, in ways we can only imagine. Therefore there is considerable noise in the community for re-writable "The Core"s. Intel is hesitant to produce such a chip, as enthusiasts are certain to defeat the "The Core"-DRM and overwrite it. I for one think lowly of such scofflaws, as supplanting "The Core" technology with anything else robs oscar-collecting Hillary Swank of the recognition she so richly deserves for the film. It is rumored an unlicnesed open-source dual-"The Matrix 1-2" port is in the works, which results in an instant 7-8 order of magnitude improvement in game quality across the board, without any tweaking! Hah, fat chance! IMHO, nothing beats an infinite-heat-capacity drilling sausage boring into a super-colossal mantle-geode plot twist.
On second thought, maybe anything does.
Most new games ARE multi-threaded. They have to be to even work in today's environments (and be worth a hoot). The problem is not an overall multithreading problem at all. It's a problem of allowing for branch code within the main processing routine. The code needs to be based more on modules supplying pieces of pertainant information back to the main thread instead of the main thread supplying information to the outlying threads. Think of it in this way; let's use how Battlefield 1942 works in multiplayer. Each user's PC is running it's own code and sending back small pieces of resultant data concerning the single user's placement and collision informationa back to the main thread, (aka main server), for integration back into the whole (the map with all of the players on it). Each piece is working independently (each individual player) yet is sharing data back with the main and the main rolls out new data to control the direction of the underling processes (data back to each individual player again).
That's what needs to happen to take advantage of multiprocessor cored CPU's. Multi-process code, not multi-threaded code. Multi-threading is old hat stuff and nearly every piece of code you see today can multithread.
I do wish the slashdot editors would consider moving ahead rapidly with their use of english. This article is extremely badly written. Possibly the editor's duel core brain is not communication between the two hemispheres?
Steve Jobs called. Something about iMac G5 and some rather unpleasant remarks about Intel.
Hate me!
Honestly, working on a dual-core CPU, you could create 2 threads-- 1 that just does character animation and silhouette/shadow volume generation, and another that does physics/AI. And you'd have very well balanced processor usage and better GPU efficiency (depending on the game of course).
Big corporate customers are slow to switch. I expect Intel to lose a few more percent in market share, but eventually they will get over the abomination called "Prescott" and release something that is a real competition for the Athlon64.
Maybe a quad-core 64 bit Dothan. At 20 Watt heat dissipation/core such a chip might be viable.
C - the footgun of programming languages
What I'd like is the ability to assign a single core to processing background apps. I run various anti-virus, anti-popup and anti-spyware applications that suck up a lot of the juice that my ancient 600mhz would otherwise make available to the rest of my system; as such, it's painful to even switch quickly between applications. Offloading those responsibilities to a dedicated core, and having the other core to use for immediate use, would be awesome.
I'm working on a driving simulator and we're wondering how to take advantage of these new dual core chips. Should one cpu handle physics and the other graphics/shadowing? Can we assign one core to each tire and have more advanced tire models? I have a funny feeling that there is about to be a huge shortage of people that can design to take advantage of the multiple CPUs.
What if Digg added local news and a Slashdot inspired comment karma system? ---
http://houndwire.com
Dual core processors let you run (a) two cores at just over half the speed of equally powerful single core processors or (b) two cores at the same speed as single core processors with nearly twice the horsepower.
In neither case will dual core processors increase memory latency. In fact, by using a slower clock speed, the memory latency is reduced in terms of clock cycles.
Further, as CPUs grow larger and larger onboard caches, they make fewer calls to main memory - and latency becomes less of a factor.
I suspect both general purpose and scientific computing can benefit from nested data parallelism.
The Nepal Project at the University of New South Wales concentrates on Multiple Program Multiple Data (MPMD). In a nutshell, any problem that can be specified as array operations can be flattened, unrolled, and automatically parallelized. This is not the holy grail of general purpose transparent parallelization of purely functional programs, but instead nested data parallelism. This extends research done in data parallel languages such as Nesl, Sisal, and really nifty algorithm shape research done in FISh.
This is the best approach to transparent parallelism that I've seen yet. Anyone know anything better?
Shae Erisson - ScannedInAvian.com
Except for the high end, Macs are single CPU computers. The Power Mac G5 is available in three dual-processor versions - and a single-processor one.
Yes, Apple has been using multiple processors for a long time - August 1996 with the Power Mac 9500/180MP. And they reintroduced the concept with the July 2001 Power Mac G4s. However, it wasn't until OS X that the Mac OS could really take advantage of multiple procesors.
As for multiple cores, if dual-core G4 or G5 CPUs were available, I'm sure they would use them. POWER is not the same thing. Apple cannot use what does not yet exist.
I assume you mean duAl-core brain. However, the idea of the separate halves dueling may also be appropriate.
people who see a monitor and think it is the computer
Uhh, Macdroid: have you ever seen an iMac? Apple is responsible for what you are blaming on Intel.
Doofus.
https://www.accountkiller.com/removal-requested
And won't until Front Side Bus speeds increase. That and data access speeds (from Hard Drives) are still and will continue to be ginourmous bottlenecks in a system. One think you have to say for Apple, a 1.25 GHz bus is nothing to balk at compared to Intel/AMD...
Intel's "dual core" hack is nothing more than 2 cores on two pieces of silicon in one convenient package. Quoting from the anandtech article covering IDF,
"Remember that chip defects increase by surface area, so manufacturing one very long piece of silicon lends itself to higher defects than two smaller pieces of silicon. Pressler, the 65nm chip we talked about earlier today, gets around this by actually using two separate pieces of silicon for the two 65nm cores - Pressler also uses the 65nm process to enable a full 2MB of cache per CPU, that's 4MB of total cache on a desktop processor."
This is a sad hack from the Intel Juggernaut. As opposed to the solution AMD built a few years ago, from scratch it was designed for a multicore future to be made from one die, hypertransport, the whole 9 yards.
I'll take AMD's dualcore over this hacked up "MODULE" intel is offering.
Do I have to deal with 2 core dumps for every SEGFAULT?
So does this mean that the next-gen celeron will be a dual-code CPU set to use only a single core because one core doesn't pass all the QA tests?
Two cores cannot be more than 2X the performance of one core, and will always be less because of resource conficts within the system/OS.
While 2X performance is nothing to sneeze at, it doesn't seem to me like game complexity is limited by the main CPU speed more than anything else. If it were, then hard core gamers would already have multiple CPU systems, and that isn't the case. So, I can only conclude that the current limit to games isn't main CPU horsepower but something else. Either that, or gamers have pushed for some other performance that doesn't require more main CPU horsepower to provide (framerate maybe?). It seems to me that gamers will have to start wanting the things that increased main CPU horsepower can give them before the game companies will respond in a big way. Either that or wait until a critical mass of multiple CPU game systems are already out there.
Will we see complexity increase? Sure. Will it happen suddenly? Probably. However, there will also be a significant lag between the availability of the dual core CPU systems and the games starting to really take advantage of them.
I couldn't disagree more.
The console will always be limited by its simplicity, i.e. no keyboard. The console was invented because little Billy, who's 5, doesn't need to know how to install the latest OS to play a game. He doesn't need to be picking out the keyboard, the sound card, any of the peripherals, it's there for him.
So since it's all prepackaged, everything has to be dumbed down to the lowest common denominator, whatever pad gets distributed with the game.
Even if you include the keyboard with the distribution, the console lives under your TV. You can't wave a mouse in the air and a keyboard on your lap is just too uncomfortable.
ALL OF THAT means that the consoles have their niche game market, FPS's, flying and driving games. (I don't even understand how the FPS's work with the freaking gamepad - aiming must be horrible - but I digress). Consoles = short, interruptable fun.
If you want strategy, true RPG, etc, etc... they simply can not be made with the same quality for the console as they can for a full fledged PC.
And also, the PC will always have the performance edge over the console. True, the console's OS can be minimal, but at the end of the day, it's either the raw speed of the main CPU or the specialized hardware (100% DirectX9.0 compliant video cards) that will win the day... there's no amount of software optimization that will win against pure hardware. The consoles will always be behind in that arena.
Besides, consider the primary output for each. Most consoles are still hooked up to TV's! Even with HDTV, modern monitors outperform them (refresh rates, resolution). Modern CRT monitor vs. regular TV - there's just no comparison.
"If you could only see what I've seen with your eyes..." - Roy Batty
local Australian coverage can be found here by the way :-)
Digital Philosopher. Looking for work.
All in all I see that Intel is going down unless they do something quick.
Did I miss the memo? Is Intel the new Apple or something? Must we keep hearing the same old bullshit speculation that, apparently "Intel is Dying!" ??
I'm no Intel fanboi (I run AMD at home) but unless the AMD chips start sucking my dick I just don't see the massive difference some of you claim is there.
Cheers
Stor
"Yeah well there's a lot of stuff that should be, but isn't"
Ok, granted the main article that this discussion forked from was about multi-cpu cores. But, it also talked about multi-threaded game programming.
It's true that you don't need multiple cpu's to take advantage of multi-threading. Something like my suggestion could probably do well in multiple threads on the same cpu, as the 'secondary' thread of execution (e.g. chat and control) really wouldn't require a lot of cpu-time.
Yes, you are correct. You can, in any program, create 'ghetto threads', by breaking up your functions in small chunks that you can call repeatedly, and setup program execution to cycle through them.
But, for doing this, it really makes more sense to break it into multiple threads. That way, you can write a simple function that loads the map/zone, and another simple function that handles chat and UI stuff, and just tell the system to run both threads. (Granted, it adds some other complexity, like which thread is controlling the screen - you'd need some communication to transfer screen control from the UI thread to the game engine thread once the map loads.) And, while the benefit would probably be negligible in this case, you do get the benefit of being able to run on multiple cpus in multi-cpu systems. And, it would still probably work ok in single-cpu/single-core systems.
When all major manufacturers move to selling primarily dual core desktops, that means your average joe, who only needs one cpu will be forced to buy two. Just think, in the future we will still need just as many computer, if not more. But intel will be effectively selling twice as many cpus as before. And don't give me "but you get two for the price of one". In retail when you get two bunches of bananas for the price of one, it's a trick to get you to buy FOUR bunches of bananas. Oh and now you need to buy some Nilla Wafers and ice cream to use up these extra "free" bananas. You can expect Intel, AMD and possibly VIA to use the same line of reasoning to justify offering a consumer-level dual core processor.
“Common sense is not so common.” — Voltaire
Intel is dying this year. They bet the farm on the Itanium and nobody wants the itanium. They expected 28 billion and only sold 1.4 billion.
I smell the stink.
Your Average Joe
If I remember correctly Intel's dual core debute is a workstation processor, while AMD will have their Opteron dual cores first.
Dual core processors make more sense in a server than a workstation.
Of course, according to Oracle, the number is actually 150%.
Freescale has been shipping dual-core 64-bit PowerPC processors since the middle of last year. Though they haven't released any press statements, they have been telling us to expect a 4-core die eval board in 8 more months. I don't know if Apple is using the 86xx series cores or if they expect too soon, but they have been available for a while now.
Another thing to remember is that PowerPCs were 'hyper-threaded' from the beginning. Even the elderly 603 could dispatch multiple instructions per clock.
I think there was something in the PIF that lets you change the speed the program operates at and the amount of ti m e the cpu i s monopolized by the program.
"He's a real midnight golfer"
Check out Lava at Xilinx, Lava at Chalmers, Hawk, the Hardware Design and Synthesis section of Haskell Application Papers on readscheme.org.
The links above lead to programs that are used by companies like Xilinx and Intel to help designers build better chips with existing technology. There are more interesting hardware approaches being investigated with Haskell. Two that come to mind immediately are quantum computing and dataflow-based simulations more related to the Lustre and Lucid languages. Though I do know of some unfinished research in the dataflow/hardware design area, I can't find any published papers at the moment.
One day I'll get around to buying a PCI card with a FPGA and use Haskell to turn it into a reprogrammable coprocessor. So many cool things to learn, so little time...
Shae Erisson - ScannedInAvian.com