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. "
It was called Bangalore to remind you where to call if you need any support for it.
Intel an American company, with the American economy in the shape it's in, I am offended at the codename Bangalore.
As the last remaining operational Soong type android, I am offended by the name Bang-A-Lore.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
> This post is copyrighted by Robert Nelson for the private use of his audience. Any other use of this post or of any pict
Your sigfile is offensive. What have ye got against the Scots?
Why is everything called cloud these days? Yet another du jour buzzword. Is this really justified here?
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
Only 48 cores? I'd ask them to double that, but reasonably, 64 cores should be enough for anybody.
If you can read this, I forgot to post anonymously.
With 48 processors you can have your system 98% idle running your typical application at full speed rather than just 50% or 75% idle as is the norm now.
Deleted
because now school administrators only have to install SETI@HOME on 100 48-core computers instead of 5000 standard computers.
Could you imagine a Beowulf cluster of Beowul.... *head explodes*
This new Cloud processor should create synergies with my SOA Portal system and allow me to deploy Enterprise B2B Push based Web 2.0 technologies!
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?
More info at:
http://www.sun.com/processors/UltraSPARC-T2/specs.xml
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).
Bad assumption. In this case, we're talking about (what you would consider) a 48 core CPU. Previous designs would have apparently contained only a small number of full processing cores, and a large number of parallel units suitable only for floating point calculations (which can be great for various types of scientific calculations and simulations). This new design contains 48 discrete IA x86 cores.
Seems like the type of processor Grand Central Dispatch was designed for.
Yaz.
That was an offshoot technology. They've finally got all the bugs ironed out and the CPU is much less prone to "uncontrolled exothermic reactions" then it use to be.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Without the West, India is still a big nothing !
And vice versa :p
Ceci n'est pas une
That's what each channel is. I forget exactly, but each DDR channel is almost 200+ pins (RDRAM was considered a big win because it is about 80). And pins == money (mainly in die area).
Why can companies not come up with decent code names. For instance, this would be the perfect case for it being codenamed "Beowulf".
They're using geographical names (cities, places, lakes, rivers) to avoid having to register the codename as a trademark. Geographical names can't be trademarked so no one will use your codename for his trademark.
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 mutex (MUTually EXclusive) is a software methodology in which one thread or process can (usually temporarily) lock a resource (such as a memory location) so that another thread or process may not access it.
It is most often required because resources are normally not 'atomic.' For instance, a string in memory is made up of many machine words and a CPU cannot read or write multiple machine word values in one operation. The danger is that while one CPU is writing to such a non-atomic collection of values, another might be trying to read from (or write to) it.. creating a situation where that second process reads part of the old data and part of the new data (essentially garbage data.)
So the idea of a MUTEX is born, in which an atomic value is leveraged to allow a thread to reserve such resources, signaling others (if they respect the MUTEX as well) to wait their turn.
"His name was James Damore."
Multiple channels and overlapped memory access? The hardware does it automatically. No need to program anything different (well, I guess there is BIOS code somewhere that configures all the channels and bank information - but most people shouldn't see that).
Now, programming a 48 core FPU monster? That is a much harder problem!
No need to program anything different Actually, I believe performance can be improved by pre-fetching data into cache ahead of time, so you know it will be there when you need it. I was doing this in software on MIPS to improve Linpack performance; I suspect you can do much the same with Intel processors as well.
GPUs are using 256 bit wide data paths now to improve data throughput; I think it is only a matter of time until the memory bus is a whole cache line (256 bits?) in width, enabling read/writing of entire cache lines in a single operation. Seems simple to me, but your pin count and power usage go up, as well as the number of separate DRAM chips you need for a wider memory bus.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Sun's processors are heavily multi-threaded per core. It is an 8 core CPU where each core can handle 8 threads in hardware. Intel's solution is 48 separate cores, doesn't say how many threads per core.
The difference? Well lots of threads on one core leads to that core being well used. Ideally, you can have it such that all its execution units are always full, it is working to 100% capacity. However it leads to slower execution per thread, since the threads are sharing a core and competing for resources.
Something like Sun's solution would be good for servers, if you have a lot of processes and you want to avoid the context switching penalty you get form going back and forth, but no process really uses all that much power. Web servers with lots of scripts and DB access and such would probably benefit from it quite a lot.
However it wouldn't be so useful for a program that tosses out multiple threads to get more power. Like say you have a 3D rendering engine and it has 4 rendering threads. If all those threads got assigned to one core, well it would run little faster than a single thread running on that core. What you want is each thread on its own core to give you, ideally, a 4x speed increase over a single thread.
So in general, with Intel's chips you see not a lot of thread per core. 1 and 2 are all they've had so far (P4s and Core i7s are 2 threads per core, Core 2s are 1 thread per core). They also have features such as the ability for a single core to boost its clock speed if the others are not being used much, to get more performance for one thread and still stay in the thermal spec. These are generally desktop or workstation oriented features. You aren't necessarily running many different apps that need power, you are running one or maybe two apps that need power.
As for this, well I don't know what they are targeting, or how many threads/core it supports.
On any vaguely recent non-Intel chip (including workstation and server chips for most architectures), you have a memory controller on die for each chip (sometimes for each core). Each chip is connected to a separate set of memory. A simple example of this is a two-way Opteron. Each will have its own, private, memory. If you need to access memory attached to the other processor then it has to be forwarded over the HyperTransport link (a point-to-point message passing channel that AMD uses to run a cache coherency protocol). If your OS did a good job of scheduling, then all of the RAM allocated to a process will be on the RAM chips close to where the process is running.
The reason Intel and Sun are pushing fully buffered DIMMs for their new chips is that FBDIMMs use a serial channel, rather than a parallel one, for connecting the memory to the memory controller. This means that you need fewer pins on the memory controller for connecting up a DIMM and so you can have several memory controllers on a single die without your chip turning into a porcupine. You probably wouldn't have 48 memory controllers on a 48-core chip, but you might have six, with every 8 cores sharing a level-3 cache and a memory controller.
I am TheRaven on Soylent News
Is there enough cpu to chipset bandwidth to make use of all this cpu power?
That's really going to depend on the intended use. And on whether the intended use involves problems that a) can be efficiently parallelized, and more importantly, b) actually have been efficiently parallelized. But unless each core gets its own memory bus and its own dedicated memory with its own cache, I rather expect that the only things that are going to be parallelized to their maximum potential are wait states. All that said, it will still probably run faster than a two- or four-core CPU for many tasks, but it won't be running 48 times faster. I would not, however, refuse a manufacturer's sample if one was handed to me. ;)
On the positive side, if this beast actually makes it to market, it might help spur the development of new parallel software.
Proud member of the Weirdo-American community.
Ugh, I hate seeing this repeated so often. The 4096-processor SGI machines that Linux works on run 'with the main tree' are clusters. They run a separate instance of Linux on each node and have some very complex hardware managing cache coherency between them. Architecturally, they are nothing like a standard SMP system.
I am TheRaven on Soylent News
> They called it Bangalore because they are going to farm out your processes.
To Maine..??
(Oh, sorry, that's Bangor. My bad!)
Uh, no. That's Bang-ah, Maine. Bangor is a Myth.
I think it's more likely we'll see kibicores and mebicores.
What is worse is that theyve done away with cache coherence. So I dont think you can take a 48 thread mysql / java process and just scale it. You COULD use forked processes that don't share much. (ie postgres/apache/php).
-Michael
It doesn't matter much. The first sibling to grab key 1a is usually running for the car. Even if the other sibling grabbed key 1b, they'll be looking at an empty parking spot, complaining to mom. :)
Serious? Seriousness is well above my pay grade.
The reason the i7 gains nothing going from double to triple channel memory is that the memory controller is power limited and so can only run at reduced clocking on triple channel configurations 800Mhz down from 1333Mhz. Of course for most workloads having 50% more data in RAM instead of glacially slow storage is a win =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
Cache coherency should be handled by the programmer, not by the hardware. Cache coherency protocols consume more bandwidth the more cores you get. The more cores you get, the more important that bandwidth becomes. At some point Cache coherency will become a bottleneck. We've been holding quite well to doubling transistor count every 18 months. If we suddenly go from strong single cores to somewhat weaker multi cores, not only will they pack more cores in for the same transistor count, but more transistors.
Imagine, our 4 core cpus will be 8 core in ~18months, then 16 ~18 more month. Intel has hyper-threading and AMD has a similar thing, so now it's like 32 cores. So, in ~ 3 years, at our current rate, we could have 32 logical CPUs reporting for low-mid sub $1.5k computers