Understanding the Cell Microprocessor
by Anand Lal Shimpi on March 17, 2005 12:05 AM EST- Posted in
- CPUs
Ordering Instructions around Dependencies
Luckily, there are solutions to the problem of dependencies in code; one tackles the problem in hardware, the other tackles the problem in software.The software compiler is responsible for producing the assembly code that is sent to the CPU for execution. Thus, with an intimate knowledge of the inner workings of the CPU, the compiler can, generally speaking, produce code that minimizes data dependencies.
There are microprocessor architectures that are dependent entirely on the compiler to extract parallelism, on the instruction level, while avoiding dependencies as much as possible. These architectures are known as in-order microprocessors.
In-Order Architectures
As the name implies, an in-order microprocessor can only execute instructions in the order that they are sent to the CPU. At best, the CPU can execute multiple instructions in parallel, but it has no ability to reorder the instructions to suit its needs better.If you have a good enough compiler, then an in-order microprocessor should be just fine. There are a couple of key limitations, however:
1. Binaries Compiled for in-order architectures are very architecture specific
Although both the Athlon 64 and the Pentium 4 are fully able to run x86 code, they contain vastly different microarchitectures, with different execution units and very different things that they are “good” at. If both of the aforementioned chips depended entirely on the compiler to extract parallelism and maximize performance, one would most definitely suffer. You could always have two versions of every program, but that tends to get large and messy - especially from an update/patches standpoint. The compiler has to be intimately aware of the architecture that it’s compiling for, which works in cases like a game console where you don’t have multiple vendors providing differently architected CPUs with a common ISA, yet not so well when you look at something like the desktop x86 market.
2. Unpredictable memory latencies
Cache is a good thing, most of the time. Cache on a microprocessor does its best to keep frequently used data at hand, so it can be made available to the CPU at very low latencies. The problem is that cache adds a level of unpredictability to how long it will take to get data from memory. A cache hit could mean that your data will be ready in 10 - 20 cycles. A cache miss could mean that it’ll be hundreds of cycles. With an in-order microprocessor, you can’t reorder instructions based on data availability, so if data isn’t available in cache and the CPU has to wait longer to pull it from main memory, the entire CPU has to sit and wait until that data is brought in from main memory. Even if other instructions could be executed, an in-order microprocessor has no logic to effectively handle the on-the-fly reordering of instructions to get around unpredictable memory latencies.
If you can find a way around the limitations of an in-order architecture, there are some very tangible benefits:
1. A much simplified microprocessor
Out-of-Order microprocessors have a significant amount of complexity added to them in order to deal with on-the-fly reordering of instructions. We will talk about them in greater detail in the next section. By moving this complexity to the software/compiler side, you greatly reduce the complexity of your microprocessor and save your transistor budget for other things that can yield better performance benefits. Less complexity also means less power consumed and heat dissipated.
2. Shorter pipeline
In order to deal with the reordering of instructions, generally speaking, a number of pipeline stages have to be added to the architecture, resulting in higher power consumption and demands for a more accurate branch predictor (thanks to an even higher branch prediction penalty). While the impact on pipeline depth isn’t as big of a deal for longer pipelined designs, for shorter designs, the increase can be 40% or more.
Historically, the idea of a simple in-order core has been one that’s been abandoned in favor of the obvious alternative: an out-of-order architecture.
Facebook
Twitter
RSS
70 Comments
View All Comments
Houdani - Friday, March 18, 2005 - link
I think I missed something fundamental.Can the SPEs be addressed directly by software, or do they have to be fed all of their instructions by the PPE?
If they DO have to be fed be the PPE, I fail to see how the PPE can possibly feed them enough to keep them all working concurrently.
Someone throw me a bone here.
suryad - Friday, March 18, 2005 - link
I thought the G5 was a POWER5 proc. But I could of course be wrong. All I can say is the Cell definitely intriguing as it may be will have a rough road ahead of it and I am quite surprised that these large corporations invested so much in it, cutting edge though it might be. And as for the current forseeable future, I think when multi-core FX processors from AMD comes out, I do not believe there will be anything more devastating than that. Especially once they hit the 3 Ghz barrier with multi-cores enabled and faster DDR2-3 or even RAMBUS memory capabilities.tipoo - Thursday, December 3, 2015 - link
No, G5 was 970 based.Questar - Friday, March 18, 2005 - link
#50,Yes the G5 is a POWER4 derivitive.
Since you were wrong on that, don't think that you know what is significant about the design of POWER5. There were major architechture changes made to the processor.
fitten - Friday, March 18, 2005 - link
The only things new about Cell is its target market and being a single chip. The article mentions the TI DSP chip, but there were other similar architectures as well. One example that I'm familiar with is the MAP1310 board by CSPI. Back then, processes weren't good enough to put all the cores on a single chip but the basic architecture is the same - a PPC core to do the 'normal' stuff and two quad-core DSPs (SHARC) to do the 'work'. This board wasn't successful because it was considered too hard to program to get the performance it promised.... and this opinion is from people who live/breathe real-time systems and multiprocessing codes.The only thing new about Cell is that a) it's all on one chip now and b) the target market is a general marketplace and not a niche.
scrotemaninov - Friday, March 18, 2005 - link
#48. OK, I was under the impression that the G5 was based on the POWER5. You're saying it's based on the POWER4 instead?And the POWER4 and POWER5 aren't really "completely different chips" in the same way that the P4 and P3 are different chips, or in the way that the P4 and the Opteron are different chips. I can give you a list of the differences if you want. Start at http://www.elet.polimi.it/upload/sami/architetture...
The POWER5 is designed to not only be completely compatible with the POWER4 but to also to support all the optimisations from the POWER4. The only things of significance they've done is a) move the L3 cache controller on chip; b) change the various branch predictors to bimodal instead of 1-bit; c) increase the associativity and size of the caches.
Anyway, this is going off topic now...
Jacmert - Friday, March 18, 2005 - link
Rofl. Computer engineering and VLSI design. Gotta love those NMOS/PMOS transistor circuits.I never thought that I'd see stuff from my textbook explained on anandtech.com
saratoga - Friday, March 18, 2005 - link
"#38. You're right that the G5 is a derivative of the POWER5. The POWER5 is dual core, each core with 2way SMT giving a total of 4 'visible' cpus to the OS. The G5 is simply a single core version of the same thing."Err no its not. POWER4 != POWER5. Hence the different names ;)
They're completely different chips.
"Well scrotemaninov I am not disputing that the POWER architecture by IBM is brilliantly done. IBM is definitely one of those companies churning out brilliant and elegant technology always in the background.
But my problem with the POWER technology is from what I understand very limitedly, is that the POWER processors in the Mac machines are a derivative of that architecture right? Why the heck are they so damn slow then?
I mean you can buy an AMD FX 55 based on the crappy legacy x86 arch and it smokes the dual 2.5 GHz Macs easily!! Is it cause of the OS? Because so far from what I have seen, if the Macs are any indication of the performance capabilities of the POWER architecture, the Cell will not be a big hit.
I did read though at www.aceshardware.com benchmark reviews of the POWER5 architecture with some insane number of cores if I recall correctly and the benchmarks were of the charts. They are definitely not what the Macs have installed in them..."
There are slow memeory systems and then theres the one used on the G5. I've heard that you can put 8 Opterons together and still get average access times across all 8 cores that are better then a single G5. Thats probably a good part of the reason the G5 was so much slower then many people thought it would be. The rest is mainly IBM's trouble making them, and their inability to ramp clock speed like they planned on.
scrotemaninov - Friday, March 18, 2005 - link
#38. You're right that the G5 is a derivative of the POWER5. The POWER5 is dual core, each core with 2way SMT giving a total of 4 'visible' cpus to the OS. The G5 is simply a single core version of the same thing.As for the performance, Opteron is pretty much unbeatable for integer-bound applications. Itanium2 is unbeatable for FP applications. POWER5 is somewhere in the middle.
Most desktop applications are going to be integer bound. So it's not at all surprising that you find the G5 'slow' in that respect in comparison to the FX55. Plus, and this is the whole problem with the CELL, there's no point putting dual CPUs in there unless you can utilise them properly. If you have one process going flat out trying to run a heavy application and it's single threaded then you're only using about 1/4 of the CPUs you've bought for that application (for a dual G5 2.5), whereas the Opterons and FX55 stuff is more designed around quick, single threaded applications.
dmens - Friday, March 18, 2005 - link
psuedo-pmos wtf? That's domino logic, it's been around forever, and it's definitely not efficient in terms of power. Oh, and it takes forever to verify timing.