Slashdot Mirror
Intel Ships Dual-Core Chips
Torrey Clark writes "Intel seems to be the first to ship a batch of dual core x86 64-bit processors to OEMs.
Intel's first dual-core chip is the Intel Pentium Processor Extreme Edition 840. The new processor runs at 3.2 GHz, backs Intel's Hyper-Threading and is supported by the company's 955X Express chipsets, formerly code-named Glenwood.
Dell also announced that it would be one of the first PC makers to ship Intel's new dual core Pentium Extreme." Reader wyckedone adds "AMD is set to ship their dual core Opteron processor, designed for servers, next week."
I want to see dual-core Pentium-Ms.
At the rate that power consumption and heat dissipation are increasing on these chips, I consider Pentium-Ms to be the only processor worth using.
If AMD is shipping in about a week, then one wonders if it's worth paying the Intel price for dual core chips when you can just wait a week and get twice as much for the same price ...
Mind you, it depends on the heat specs.
-- Tigger warning: This post may contain tiggers! --
about manufacturers charging per-core licenses for their software. For more info, read this.
While the idea of dual core cpus is really cool, and will take over shortly due in part to the fact that we need something to do with all those extra transistors, I wonder why the focus of the industry is on chip multi-processors (CMP).
.
While CMP processors can give us rougly the same performance of a standard SMP system (somewhat faster due to interprocessor communication and shared memory, but also slower due to a larger memory bottleneck) I don't think that a CMP system would compete with a simultaneous multi-threading (SMT) solution.
While Intel's response to SMT (hyperthreading) has some benifits the performance of it is rather lackluster. The reason has more to do with their particular implementation. If you've read about the initial observations on SMT an 8-way SMT processor was shown to outperform a 4-way CMP processor. Now, I must note that the 8-way smt processor had more functional units then the cores in the 4-way CMP processor, but the overall area of the 8-way SMT processor would be much much smaller (far less structures need to be duplicated for SMT as opposed to CMP). For more information on this check out some of the papers at http://www.cs.washington.edu/research/smt/
What I don't understand is the insistance of the industry to use CMP first. From everything I've read, an 8-way SMT processor should take up less die space then a two way CMP processor. Even assuming that the 8 way processor contains more functional units. It kind of makes sense that a CMP processor is faster when there aren't enough threads to fully utilize a SMT processor (say only 2 or 3 threads that want full cpu usage). I guess SMT is a big chance in the model of programming and application development (I'm currently running research on the subject which is why I'm so interested in it). Is the reason to embrace CMPs simply because there's less new technology to add (they "just" have to interconnect two cores as opposed to adding the extra logic for SMT).
Does anyone else have any other opinions regarding this matter, or any idea why no one seems to be fully embracing SMT's potential?
I see lots of conversation comparing this generation of processor to space heaters, wisecracks about Longhorn minimum systems (that actual article was about the predicted "average", not minimum). Not much about actual multi-cores. They're an interesting direction to go.
The current direction of single core CPUs is basically running into the most they can do with XUs, MPUs, caches, etc. Sure, you can decrease the pipeline depth below the 18FO4 that the PentiumIV supposedly has, and that can help you with serial data paths, and that makes simple XUs, MPUs, etc. faster, but the branch mispredict is still horrendous -- perhaps too high for a general purpose processor found in our PCs. The more complicated logic is possible to do, but there's only so much you can do with the data and sub-Angstrom logic.
Beyond the geek factor, multiple cores on a single die attack the same problems as putting SMP did in the first place (plus a few race conditions that otherwise may have been very rare), allowing much less manpower to design a processor that is still much faster in the end. A single threaded application will seem slower, and that will place more burden on the developers to see the light of multiple threads. Instead of allowing an XU to munge through and deal with a single thread at a time, which may be a misuse of incredible resource (like a thread that said "go to grocery store" and the XU was a race car), multiple die have correspondingly multiple XUs each with their own resources, so hard tasks can be spread across multiple cores, or simple ones can get executed in parallel with others (like a thread can take a Kia to the grocery store while another Kia goes to the Post Office). Of course, problems that cannot be divided into multiple threads do not see the advantage of multiple cores, but other tasks remain responsive without requiring a monster task to context switch.
I've read about multiple cores that share a single L2 outperforming multiple cores with dedicated L2s in specific tasks, basically one core essentially acts like a pre-fetch core under a workload and the second core can reap the benefits.
Has anyone stopped to look at modern software while thinking about Dual-Core?
Both Intel and AMD have decided upon dual-core as the future of desktop computing. There will be no more massive Mhz increases... instead the focus is now on parallel computing.... But, seriously, how many CPU intensive applications outside of the server arena take advantage of SMP?
As someone who has ran dual-cpu workstations for years, I can personally attest to the fact that 99% of CPU heavy tasks do not make use of SMP.
Think about it... That copy of Doom3 or Half-Life 2 that you just bought, that runs like shit on even top-of-the-line hardware, isn't going to run any better on Dual-Core, because these games are not designed to run multiple threads simultaneously. Neither do most archival programs (WinAce, WinRar, WinZip, SevenZip, etc etc). Nor do many of your encoding tools (though FlaskMPEG and GoGo-No-Coda are noteworthy exceptions).
As a geek, I can attest that the *nix arena isn't much better. Just because the source is open and available does NOT mean that the author(s) ever considered coding CPU intensive tasks for multiple processors. And "porting" tasks from single threaded to multiple threads is NOT a simple task. This is one of the reasons that there are Computer Science degrees -- writing good SMP code isn't something you learn at technical schools (or even half the full Universities out there).
Don't get me wrong... as someone who has ran SMP boxes for the past 10 years, I'm really excited about Dual-Core. But don't expect it to be worth a whole lot for the immediate future... as no one outside the server arena really codes for SMP.
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.
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.
Having two non-identical CPUs in the same package, or in the same machine, isn't that useful. Typically, the "wierd" ones sit idle unless whatever application that specifically uses them is running. The operating system usually has no idea what to do with the "wierd" processor, so it gets managed as a peripheral, which doesn't work very well.
There were some wierd Mac variations in the 1980s with a second CPU on a plug-in board. They could run Photoshop faster, but otherwise were useless.
There are really only two multi-CPU architectures that are generally useful: shared-memory symmetrical multiprocessors, and networked clusters with no shared memory. Many other architectures have been tried - partially shared memory machines, shared-memory machines where some CPUs lacked some features like floating point, hypercubes, single-instruction-multiple-datastream machines, and dataflow processors. None has achieved lasting success.
About the only unusual architecture ever sold in volume is the Playstation 2, with two vector processors. Even there, the vector processors are mostly used as a GPU. (Although one major game physics engine actually runs in the PS2 vector processors, an impressive achievement.)
Programming for wierd architectures is hard, requires much tool development, and results in programs tied to specific hardware. So it doesn't happen much. That's why the wierd architectures fail. They're never that much faster, and by the time the software works, the hardware market is somewhere else.
Okay, sorry about the dumb ass question here, but I can't seem to find an answer:
Are AMD's and/or Intel's processors supposed to work in existing motherboards (err at least with SOME benefit...) or does upgrading to a dual core machine mean getting a new mobo?
"Derp de derp."
We can barely code for two processors let alone beasts like the TMS320C62. Ignoring this for a second, what kind of memory are you proposing to feed all of these processors?
There are places where we have 'surpassed' von Neumann architecture. Surprise surprise its surpassed for things such as imaging applications. FPGA and ASICs beat Pentiums/Athlons in imaging applications hands down. For much less cost at that.
Intel has ten fabs and ten times the capaciy.
It's not about who has a better product, it's about ability to supply that keeps Intel monopoly going.
And the price goes up. This is simple economics. If this were the case, AMD would be able to knock the price up an arm and a leg. In time (supposing Intel could not match it), AMD can build more fabs using the newly generated income, while still making chips. I would imagine that if the demand was there, AMD would take the risk and build more plants right away. It is as simple as that. The Intel monopoly would only be able to last so long.
JM
This is Intel faxing something to market. This is another one of their paper launches.
I thought that AMD is slated to ship their dual core chip first?
They are. This "news item" is so full of pro-Intel baloney it has to be a paid placement. AMD started shipping their dual core Opterons to OEMs a couple months ago. HP will have a dual-core Opteron server available for immediate delivery on AMD's release date of April 21. Intel wanted really badly to be first with dual core processor release, mainly because their x64 processors are such turdburgers, but they didn't do it. Rushing out a few pilot-run processors to Dell is too little, too late - there will be not be any actual computers using Intel dual core processors available on April 21. There will be dual core Opteron servers and workstations available that day. AMD is first again.
I cannot recall ever hearing Intel sound so desperate. First they ship pre-release samples to a handful of friendly reviewers and then they announce that they have 'shipped' the product, apparently to beat AMD's planned announcement on April 21 but the sum total of the evidence for the alleged 'shipment' seems to be a claim that they have shipped the product to Intel-friendly Dell. No one seems to actually have it to sell anywhere and even Dell just says they will be shipping 'soon.' In better days, Intel used to send a new product around to reviewers under NDA a few days before an actual release. The NDA would expire on the day of the product announcement and then you would actually be able to buy it at the time it was 'released.' How times have changed for Intel...and for AMD.
No. If you ever read about any of the roadmaps, you'd know. Smithfield: the first dual-core processor, which is two Prescott dies welded together. No big news. Then a family at that level. Then the big one, Cedar Mill. This was designed with dual-core in mind. I won't talk about the real performance, because I'm not allowed to. But let's say Smithfield is paving the way. I know /. is a big supporter of the underdog in most cases, but really man, read the roadmaps for both companies, and you'll learn that Intel has a huge dual-core product lineup, which dates back before AMDs Opteron announcements.
Dell "said it would begin shipping its Dimension brand of PCs with the new chips relatively soon with prices starting at around $3,000."
So why would you pay 3000 bucks for two throttled CPUs on one die, if you could get a dual PROCESSOR system for the same price? I mean, the second heat sink is not going to raise the price of the system to another level... and you can go with proven technology.
Actually, I would only consider a dual AMD64 system worthwile. With NUMA support improving in Linux, this should be a lot faster than 2 P4 cores competing for the same memory, already suffering from high latency.
This is true.
I'm employed as a DSP/FPGA programmer. I'm currently working with a chip (ADI Blackfin) that can encode realtime MPEG2 audio/video at a blazing fast 300MHz, while dissipating half a watt of heat. And the chip costs ~$10 USD! Yet I remember the big thing on Tom's Hardware a few years back when a close-to-$1K, ~1GHz P3 or Athlon pushing 30-40 watts of heat finally could do realtime MPEG2.
(and this DSP chip does plenty more than MPEG encoding. It even runs Linux.)
The x86 architecture is old and just "too flexible" - It's not fundamentally designed for many of the things that we do with today's computers. Things like audio/2D-video processing are suited for DSP architectures, and 3D graphics are suitable for vector processors. The x86 architecture can thrash away with add/shl/cmp/call instructions and get these things done - but only when it's running brutally fast with huge caches and putting off gobs of heat in the process.
You can only play that game so long - eventually, the fundamental architectures of computers will have to change and things will have to become more specialized for the things they do. Personally, I'm anxious to see things like DSP cores and maybe even small reconfigurable FPGA cores integrated into CPUs...