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.
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.'"
hence the block of RAM per CPU.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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!
No doubt a dual core processor will incur a dual cpu license fee as well.
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?"