Understanding the Cell Microprocessor
by Anand Lal Shimpi on March 17, 2005 12:05 AM EST- Posted in
- CPUs
Cell’s Approach - In Order with no Cache
Remember that the Cell’s architects designed the processor while evaluating the incremental performance each transistor they used resulted in (somewhat exaggerated, they didn’t count every last one of the 234 million transistors, but they evaluated each architectural decision very closely). In doing so, the idea of in-order vs. out-of-order must have raised a huge debate, given the increased complexity that an out-of-order core would add.With the major benefit of out-of-order being a decrease in susceptibility to memory latencies, the Cell architects proposed another option - what about an in-order core with controllable (read: predictable) memory latencies?
In-order microprocessors suffer because as soon as you introduce a cache into the equation, you no longer have control over memory latencies. Most of the time, a well-designed cache is going to give you low latency access to the data that you need. But look at the type of applications that Cell is targeted at (at least initially) - 3D rendering, games, physics, media encoding etc. - all applications that aren’t dependent on massive caches. Look at any one of Intel’s numerous cache increased CPUs and note that 3D rendering, gaming and encoding performance usually don’t benefit much beyond a certain amount of cache. For example, the Pentium 4 660 (3.60GHz - 2MB L2) offered a 13% increase in Business Winstone 2004 over the Pentium 4 560 (3.60GHz - 1MB L2), but less than a 2% average performance increase in 3D games. In 3dsmax, there was absolutely no performance gain due to the extra cache. A similar lack of performance improvement can be seen in our media encoding tests. The usage model of the Playstation 3 isn’t going to be running Microsoft Office; it’s going to be a lot of these “media rich” types of applications like 3D gaming and media encoding. For these types of applications, a large cache isn’t totally necessary - low latency memory access is necessary, and lots of memory bandwidth is important, but you can get both of those things without a cache. How? Cell shows you how.
Each SPE features 256KB of local memory, more specifically, not cache. The local memory doesn’t work on its own. If you want to put something in it, you need to send the SPE a store instruction. Cache works automatically; it uses hard-wired algorithms to make good guesses at what it should store. The SPE’s local memory is the size of a cache, but works just like a main memory. The other important thing is that the local memory is SRAM based, not DRAM based, so you get cache-like access times (6 cycles for the SPE) instead of main memory access times (e.g. 100s of cycles).
What’s the big deal then? With the absence of cache, but the presence of a very low latency memory, each SPE effectively has controllable, predictable memory latencies. This means that a smart developer, or smart compiler, could schedule instructions for each SPE extremely granularly. The compiler would know exactly when data would be ready from the local memory, and thus, could schedule instructions and work around memory latencies just as well as an out-of-order microprocessor, but without the additional hardware complexity. If the SPE needs data that’s stored in the main memory attached to the Cell, the latencies are just as predictable, since once again, there’s no cache to worry about mucking things up.
Making the SPEs in-order cores made a lot of sense for their tasks. However, the PPE being in-order is more for space/complexity constraints than anything else. While the SPEs handle more specified tasks, the PPE’s role in Cell is to handle all of the general purpose tasks that are not best executed on the array of SPEs. The problem with this approach is that in order to function as a relatively solid performing general purpose processor, it needs a cache - and we’ve already explained how cache can hurt in-order cores. If there’s a weak element of the Cell architecture it’s the PPE, but then again, Cell isn’t targeted at general purpose computing, despite what some may like to spin it as.
The downsides of an in-order PPE are minimized as much as possible by making the core only 2-issue, meaning that at best, it could execute two operations in parallel. So, execution potential lost to in-order inefficiencies are minimized in a sense that at least there aren’t a lot of transistors wasted on making the PPE an extremely wide chip. A good compiler should be able to make sure that both issue ports are populated as frequently as possible, despite the fact that the microprocessor is in-order. The PPE is also capable of working on two threads at a time, also designed to mask the inefficiencies of an in-order core for general purpose code.
Architecturally, if anything will keep Cell out of being used in a PC environment, it’s the PPE. A new Cell with a stronger PPE or an array of PPEs could change that, however.
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.