Slashdot Mirror
Intel Shows 48-Core x86 Processor
Vigile writes "Intel unveiled a completely new processor design today the company is dubbing the 'Single-chip Cloud Computer' (but was previously codenamed Bangalore). Justin Rattner, the company's CTO, discussed the new product at a press event in Santa Clara and revealed some interesting information about the goals and design of the new CPU. While terascale processing has been discussed for some time, this new CPU is the first to integrate full IA x86 cores rather than simple floating point units. The 48 cores are set 2 to a 'tile' and each tile communicates with others via a 2D mesh network capable of 256 GB/s rather than a large cache structure. "
Microsoft once had a podcast where they were talking about multi-core CPU kernels. Their belief was that once you had 50+ cores, you would be able to have a mutex for every single COM object element, simply because you could.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Unlike Stanford University, UCSB lacks the money to build a full-blown multiprocessor system. If UCSB had such a system back in the 1990s, then UCSB would likely have produced as much multiprocessor research as Stanford University.
This 48-core processor chip, due to the fact that it will eventually be a commercial product mass-produced by the millions of units, will be economically cheap. This chip will enable UCSB to build or buy a cheap multiprocessor system.
A bunch of graduate students is already salivating at the prospect. They are drooling.
Is there enough cpu to chipset bandwidth to make use of all this cpu power?
Can someone elaborate on why you'd want 48 full processors, rather than a processor with two (dual) or four (quad) "cores" (I'm presuming core in this case == FPU in the article). Supposedly Win7's SMP support becomes much more effective at the 12-16 core thresehold.
The first thought comes to mind if video processing and CGI animations because those applications are embarrassingly parallel.
And those companies usually have the money to spend on top of the line hardware.
Eventually this will trickle down to consumer level as always and people at home can now do real time movie quality CGI on their home computers in 10 years.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
A cache line on a modern Intel/AMD processor is actually 512 bits, or 64 bytes.
A memory bus 512 bits wide wouldn't really help much, though -- right now when dealing with memory, most of the time is spent in the various latencies. When you are fetching a lot of memory sequentially, you can get insane speeds even today. But that's not how you usually read memory -- instead, you read a few words from different locations, and the memory controller needs to activate the correct bank, row and column before you get what you need. On typical PC-10600 DDR3, that means at least 15 bus cycles just waiting around for the memory to adjust. Making the bus 512 bits wide would speed up the actual transfer to one bus cycle from the 4 what it takes currently, but that would only mean an improvement of about 15% -- at a huge cost for having to accommodate those 384 extra data lines on the chip, socket, motherboard and ram. It's better just to try to speed up the memory so burst transfers happen "fast enough".
I don't know about nvidia cards, but at least for ati the card doesn't actually have a 256 bit memory interface -- instead, it has 4 completely separate 64-bit memory channels connected to a fast ring bus. The interleaving of data on those separate memory channels is done very coarsely -- basically, entire textures and such are allocated on a single channel. This means that when that texture is being fetched, the 3 other channels can serve other requests.
This is the way I see cpu's evolve too -- even on current hardware, namely phenom 2, you get better performance when you ungang the memory channels, and wait 8 cycles for a single memory transfer instead of 4, because that way you get to wait on separate latencies on the separate channels at the same time. Of course, in the perverse case all the data you want to access resides on one of the channels, but the chance of that happening by accident is pretty much nil.