Slashdot Mirror
Dual Caches for Dual-core Chips
DominoTree writes "The dual-core chips that AMD and Intel plan to bring to market next year won't be sharing their memories. A version of Opteron coming in 2005 and Montecito, a future member of Intel's Itanium family also slated for next year, will both have two processor cores, the actual unit inside a processor that performs the calculations, and each core will have separate caches."
I'm not a hardware pro, but is this basically the same as having two seperate chips, or am I missing the point here?
What will happen to those who must pay a royalty fee per CPU? Will companies that charge for each CPU begin to charge for two, or will it still be viewed as one...?
Real programmers can write assembly code in any language. -- Larry Wall
You probably don't want to have both chips fighting over the cache, and slowing things down; I'm sure doing The Right Thing[tm] will take a while for them to work out. Until then, just pretend that they're mostly separate chips on the same silicon.
Maybe in the future they'll come up with some more advanced cache designs that can share some cache and improve performance. But until then, expect to see it in the next generation of value chips. (Overclocked dual-core Celerons? Nifty!)
pb Reply or e-mail; don't vaguely moderate.
Hmm... the Power4 is dual-core and unified cache? I wonder if this has implications for future Macs to compete with these new x86 processors...
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
We have a dual p4 server, the damn thing sounds like a gas turbine when it's on. Really, I've used quieter air compressors.
Our dual-G5s from apple are quiet, sleek, and each processor gets it's own block of RAM. Granted, the ASIC for the memory controller gets it's own heat sink. But man, you crack it open and you wonder where the rest of the server is. It's literally 2 giant blocks for the processors, the ASIC that handles memory management, and a wee little chip on the end of the mobo that looks like a bus controller.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
The benefits of HT, as currently implemented, are pretty insignificant compared to the benefits of multiprocessing, as the possible performance boost is very small, it certainly doesn't give you the ability to handle more interrupts, and it doesn't let you decrease the number of context-switches.
As for building a more intelligent core to take advantage of the extra transistors, that just might make sense - but it would also take hundreds of millions (or billions) of dollars in development, and the chip wouldn't appear for a good number of years (look at the Itanium). It's a lot easier and cheaper to slap two cores on the same die and call it done. Because Intel is scurrying to try and play catch-up to AMD in the high-end market, time-to-market is critical for them.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
Apple isn't scheduled to release the first 64-bit version of OS X until the first half of next year and even then, it is not guaranteed to be fully 64-bit (though this is what most people, including me, believe).
Oceania has always been at war with Eastasia.
Can I have a 64bit OS too please? (no not linux)
Why not Linux? Most 64-bit ready OS's these days are Linux (SUSE 9.1, FC2, Gentoo) or Unix-ey (MacOS X).
So it's pretty much tough shit for you then. Microsoft has abandoned you, their 64-bit OS will not be out until late 2005 (but you can have their crummy beta for free). Bahahahaha.
The dual cache simplifies things emormously, especially taking the design of the Opteron into account. Opterons are incredibly scalable--each one has three HyperTransport links that can be connected to memory, I/O or another processor. In order to make dual-core chips, all AMD has to do is take two Opterons, put them in the same package and hard-wire a HT link from one processor to the other.
Of course, they also need to worry about things like size and power consumption but the simplified architecture really makes things a lot easier and will probably contribute to lower prices. It will also accelerate the introduction of multi-core (ie more than two) processors...
If they were to implement a unified cache design, they would have to make significant changes. They would need to implement cache snooping and complicated memory management. Given that the new dual-core processors (AMD ones, at least) are meant to be pin-compatible with current processors, this would be a bit much to ask. Maybe they'll have unified caches sometime, but I don't see it happening anytime soon.
Don't you hate meta-sigs?
The Hammer-core processors with dual-channel memory controllers have more memory bandwidth than the best G5, and the memory is accessed directly by the processor. Hypertransport is really quite an excellent interconnect. Hammer is NUMA-architecture and each processor gets its own block of ram. Finally, the Opteron dissipates much less energy as heat than the intel offerings - only about 46W max. I believe this is still a bit more than the G5, of course, but it's really not that bad.
So yes, the proper term is compete.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
A friend purchased a 3GHz( yes 3 ) Intel Pentium 4 with HyperThreading a few months back. I asked why he didn't purchase an AMD CPU and he said he needed x86 compatibility... So much for informed hardware engeers. Anyway, I recently asked him about the system since I just built an AMD 2600+ based system and wanted to know if he had some code he wanted to compare/test. Well, he told me that his 3GHz CPU really only runs most applications at 1.5GHz except if they are multi-threaded or hyperthread aware.
Is this true? Does Intel put a 3GHz label on 1.5GHz dual/core CPU's or whatever this hyperthreading is? Sounds dual/core-ish to me...
It's funny how that 1.5GHz number shows up again in Intel product. I remember when they could not build anything faster than 7xxMHz and then all of a sudden, they had a "new technology" that got them 1.5GHz( 2x 750MHz ) and it was found out later that only PART of the CPU was running at 2x. This all happened when AMD beat Intel passed the 1GHz barrier. Are they again playing "tricks" to get a big GHz label on their parts?
So any of you people up on this dual-core and hyperthreading thing and feel like explaining to the rest of us what's going on? TIA.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Is it going to hurt Microsoft that they aren't releasing a real 64-bit operating system for another year and a half?
I tend to see the possibility that people who buy 64-bit computers will try to take advantage of their capabilities by choosing 64-bit capable operating systems to run on them. Even Itanium users would have little or no interest in running a beta version of Windows when they could have a real, tested, released operating system like Linux for cheaper. This may potentially even help Linux with hardware support, and encourage 64bit vendors to use more capable hardware.
On the other hand the 80386 processor (the first to have 32-bit capabilities) was released in 1985. It wasn't until 1992, 7 years later, that Microsoft came along with an OS (Windows NT) that took advantage of the 80386's 32-bit architecture. It was 3 more years after that before Windows 95 brought those features to the consumer market, which Microsoft promptly dominated.
Will Microsoft's delay in releasing a 64bit operating system hurt them? Will it make a difference?
hence the block of RAM per CPU.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Are the dual cores on the same piece of silicon? This would require both cores to be defect free. If only one core is defect free, is it possible to disable the dud and sell it as a single core CPU? This would make it a much more attractive proposition for the manufacturers.
E.g. if a single core has a yeild (probability of being defect free) of 80%, then the dual core chips will have a yeild of 0.8^2 = 64%. (Actually slightly lower, because whatever interconnect they have also has to be free of defects.) 64% will have two good cores, 4% will have two bad cores, the remaining 32% will have one good core. The manufacturer would obviously like to make use of that 32% if they can.
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
True, and someday every IO process will probably be handled by a dedicated processor. A distributed operating system will run processes on each, making it easy to reprogram the tasks. Fast interconnects will make a NUMA architecture possible.
Currently however that future is far off. It's simply much cheaper to centralize processing, so the bus will remain an issue for some time to come. For most situations this will be fine, for specialized situations where a single (fast) real time process is needed, or when IO is more important than CPU power...it sucks.
(listening to my integrated audio which takes about 7% of my processor, and I don't care a bit)
Motorola (Freescale) have already announced that they have announced that they will have dual core g4s available this autumn (I assume as engineering samples).
They are aiming this at Mac Notebooks.
I beleive IBM have already planned a roadmap for the g5 that includes dual core.
Go out and get sailing!
So all those people waiting for G5 Powerbooks are going to end up with dual-core G4 ones instead?
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
It's not a question of if there will be 64-bit OS's to go with these things. Eventually, it's sure to happen in multiple flavors.
The real question is what ELSE will be on the motherboards and in the chip by the time these things hit the market? Specifically, what DRM hardware will come with these things? What will the BIOS look like?
That's why I think that the current generation of 64-bit desktops are probably one of the best values for a machine you might be using 4 years from now. It's risky to wait 6 months or a year with the current views of the US Congress and FCC. This generation of 64-bit machines might be one of the last to be multi-purpose Turing/Von Neumann devices.
Don't wait for dual-cores if you have the cash and want to be the one in control of your 64-bit machine. Eventually the OS's will catch up.
"Let him go, Ralph. He knows what he's doing." --Otto Mann (simpsons)
You laugh.. but that's exactly what I've seen happen on Mac OS.. One processor panics, but you're still dragging a window around because one is still running.. (That doesn't last long, though..)
No doubt a dual core processor will incur a dual cpu license fee as well.
Would it be possible at such small levels to make the processor interconnect very very fast and very low latancy? I'm sure HT (Hyper Transport) is designed as a very robust error checking protocol, surely it must be possible on this scale to get 3ghz or more out of what is meant to be a Chip to Chip interconnect. Also, what are the problems with allowing either processor to access memory as and when it is needed? I.E. Wiring the memory controller of both processors to the pins and making a realtime decision based upon which core has access to memory? This would reduce latency a lot for the second core.
With a 32-bit OS and 32-bit applications you can only access a maximum of 2 or 3GB of data at a time (possibly even less due to memory fragmentation). This may or may not affect what you do.
If you do indeed have files as big as DVDs, it would certainly help with editing those files. You CAN break those up into chunks, only having 2GB or less in memory at any given time, and for the most part this works ok, however it does tend to be a bit of a kludge at the best of times, and sometimes it just flat out doesn't work.
As you correctly guess, servers are the first situation where this really makes sense. If you've got a database that is more than 2GB in size, you REALLY want a 64-bit system, otherwise you'll tend to take a big performance hit. Many high-end workstations require 64-bit systems as well to process all the data.
So, where is the benefit for the end-user? Well that depends on the user. First off, having more than 2GB of physcial memory on a 32-bit processor requires some really ugly hacks to make things work. They do work, but it is a really dumb idea. It was a annoying and crappy when we were forced to do it back in the 16-bit days, and it hasn't gotten any better. Secondly people are using bigger and bigger data files on their home PC, editing larger pictures and videos, playing games with more graphics and sound, some even run into issues with types of databases (I know my Usenet newsreader sometimes craps out when I'm downloading too much pr0n because of database limits). Basically you might not need it, but someone else might. The best part about it though is that 64-bits is "free".
Basically you've got a 64-bit CPU that is no more expensive than competiting 32-bit chips and Microsoft has said that 64-bit WinXP Pro will sell for the same price as 32-bit WinXP Pro, so really the question is not so much "Why" do we need 64-bit, but "why not?"
That's very interesting: you just said cache = silicon = cost.
...welcome to Itanium.
But this is oversimplifying things, and that is, IMO, one of the key insights into why the itanium architecture will prove superior and win in the end.
"Cost" means many different things. There's a cost to _manufacture_ the silicon, but there are also costs associated with designing the silicon, and costs associated with "running" the silicon (I mean power consumption, heat dissipation etc).
The great thing about cache is that the latter two costs are almost zero - the design cost is basically nothing (you cut and paste, quite literally) and the power consumption is very low because only a tiny fraction of the transistors in cache actually switch value in any given clock cycle. Yes, there's static leakage power to worry about as well, but with things like adaptive voltage biasing Intel (and others) are well on their way to getting a hold of leakage as well.
The Itanium architecture is designed to shine in the era of billion, and indeed 10-billion transistor CPUs, which is coming very soon (the next two to ten years, basically).
There's no way Intel (or anyone else) can even afford to hire 50 times as many design engineers as they to currently, so they have to think about more clever ways of spending their transistor budget.
There are two ways,really: more cache, and more execution resources. You can cut and paste cache, and you can cut and paste things like ALUs and FPUs. Of course, you would need a wide-issue instruction architecture to take advantage of all of these.