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.

Out-of-Order Architectures Manufacturing, Die Size and Clock Speed
Comments Locked

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.

Log in

Don't have an account? Sign up now