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
scrotemaninov - Thursday, March 17, 2005 - link
#23: True, but I believe that when the SPE's access the outside memory they go through the cache. Sure it's a lower coherancy than we're used to but it's not much worse.Houdani - Thursday, March 17, 2005 - link
18: Top Drawer Post.20: Thanks for the links!
fitten - Thursday, March 17, 2005 - link
"Given the speed of the interconnect and the fact that it is cache-coherant,"Only the PPC core has cache. The individual SPEs don't have cache - they have scratchpad RAM.
#22: I believe the PPC core is a dual issue core that just happens to be 2xSMT.
AndyKH - Thursday, March 17, 2005 - link
Great article.Anand, Could you please clarify something:
I had the impression that the PPE was a SMT processor in the sense that it had to be executing 2 threads in order to issue 2 instructions per clock. In other words: I didn't think the PPE control logic could decide to issue 2 instructions from the same thread at any given clock tick, but rather that it absolutely needed an instruction from each thread to issue two instructions.
After reading the article, I don't assume my impression is right, but a comment from you would be nice.
As I come to think about it, my impression is rather identical to 2 seperate single thread in-order cores. :-)
Koing - Thursday, March 17, 2005 - link
Cell looks VERY interesting.Any of you guys seen Devil May Cry 3 on the PS2? Looks great imo same with T5 and GT4.
Cell at first will be tough like most consoles. BUT eventually THE developers will get around it and make some very solidly good looking games.
Lets hope they are innovative and not just rehashed graphics and nothing else.
Thanks for the great article.
Koing
scrotemaninov - Thursday, March 17, 2005 - link
I really hate just dumping loads of links, but this basically is the available content on the CELL.http://arstechnica.com/articles/paedia/cpu/cell-1....
http://arstechnica.com/articles/paedia/cpu/cell-2....
http://realworldtech.com/page.cfm?ArticleID=RWT021...
http://www.blachford.info/computer/Cells/Cell0.htm...
http://www.realworldtech.com/page.cfm?ArticleID=RW...
http://www.hpcaconf.org/hpca11/papers/25_hofstee-c...
http://www.hpcaconf.org/hpca11/slides/Cell_Public_... (slides)
mrmorris - Thursday, March 17, 2005 - link
Brilliant article, there are few places for in-depth hardcore technology presentations but Anandtech never fails.scrotemaninov - Thursday, March 17, 2005 - link
Real concurrency is hard to do for the programmers. It's a real pain to get it right and it's hard to debug. Systematic analysis just gets too complex as there are just too many states, you end up with a huge graph/markov-model and it's just impossible to solve it tractably.Superscalar and SMT just try to increase ILP at the CPU level without burdening the programmer or compiler-writer. However, we've pretty much come to the end of getting a CPU to go faster - at 5GHz, LIGHT travels 6cm between clocks, and an electic PD will travel slower. As it is, in the P4 pipeline, there are at least 2 stages which are simply there to allow signals to propogate across the chip. Clearly, going faster in Hz isn't going to make the pipeline go faster.
So the ONLY thing that they can do now is to put lots of cores on the same chip and then we're going to have to deal with real concurrency. IBM/Sony are doing it now with CELL and Intel will do it in a few years. It's going to happen regardless. What we need is languages which can support real concurrency. The Java Memory Model is an almost ideal fit for the CELL, but other aspects don't work out so well, maybe. We need Pi-calculus/Join-calculus constructs in languages to be able to really deal with these cpus efficiently.
Your comments about CELL not being general purpose enough are a little wrong. IBM /already/ has the CELL in workstations and are evaluating applications that will work well. Given the speed of the interconnect and the fact that it is cache-coherant, I think we'll be seeing super-computers based on many CELLs, it's an almost ideal fit (as it is, you've almost got ccNUMA on a single chip). Also, bear in mind that this is IBM's 5th (or 6th?) generation of SMT in the PPE - they've been at it MUCH longer than Intel - IBM started it in the mid-90s around the same time that the Alpha crew were working on the EV8 which was going to have 8-way thread-level parallelism (got canned sadly).
Also, if you look at IBMs heavy CPUs - the POWER5, that has SMT and dispatches in groups of 8 instructions, not the 3/4 that AMD/Intel manage.
What I'm saying here, is that sure, the SPEs don't have BPTs of BTBs, they're all 2-way dispatch and not greater, but, they all run REALLY fast, they have short pipelines (so the pain of the branch misprediction won't be so bad), and, IBM have had software branch prediction available since the POWER4, so they've been at it a few years and must have decided that compilers really can successfully predict branch directions.
Backwards compatibility doesn't matter. Sure, Microsoft took several years to support AMD64 but that didn't stop take up of the platform - everyone just ran Linux on it (well, everyone who wanted to use the 64bit CPU they'd bought). It'll only be a few months after the CELL is out that we'll have to wait until Linux can be built on it. 100quid says Microsoft will never support it.
Frankly, considering that it's far more likely to go into super-computer or workstation environments, no one there gives a damn about backwards compatibility or Windows support. No one in those environments /wants/ a damn paper clip.
Reflex - Thursday, March 17, 2005 - link
#14: Replace 'lazy developers' with 'developers on a budget' and you will have a true statement. Its not an issue of laziness, its an issue of having the budget to optimize fully for a platform.GhandiInstinct - Thursday, March 17, 2005 - link
Wow Super CPU and SUPER RAMBUS? AHHHH!This will replace my computer. PS3 that is.