Understanding the Cell Microprocessor
by Anand Lal Shimpi on March 17, 2005 12:05 AM EST- Posted in
- CPUs
Cell’s In-Order Architecture
We have mentioned that both the PPE and SPEs are in-order cores, but in order to understand the impact of an in-order core on performance, there’s a bit of background knowledge that we have to go over first.Dependencies, Instruction Ordering and Parallelism
What are Dependencies?In many of our past CPU articles, we’ve brought up this idea of dependencies as seen by the CPU. At the very basic level, a CPU is fed a stream of instructions that are generally of the form:
OP destination, source1, source2, ... , source n
The instruction format will vary from one CPU ISA to the next, but the general idea is that the CPU is sent an operation (OP), a destination to store the result of the operation, and one or more sources on which to get data to perform the operation. Depending on the architecture, the destination and sources can be memory locations or registers. For the sake of simplicity, let’s just assume that for now, all destinations and sources are registers.
Let’s take a look at an example with some data filled in:
ADD R10, R1, R2
The above line of assembly would be sent to the CPU, telling it to add the values stored in R1 (Register #1) and R2 and store the result in R10. Simple enough. Now, let’s give the CPU another operation to crunch on:
MUL R11, R10, R3
This time, we’re multiplying the values stored in R10 and R3, and storing the result in R11. As a single line of assembly, the above code is easily executed, but when placed directly after our first example, we’ve created a bit of a problem:
- ADD R10, R1, R2
- MUL R11, R10, R3
- ADD R9, R11, R4
The problem with a dependency is that it limits what can be executed in parallel. Take the Athlon 64, for example. It has three integer execution units, all of which are equally capable of executing the code (in a slightly revised, x86 assembly format, of course) that we used above. In theory, the Athlon 64 could execute three lines integer operations in parallel at the same time - assuming that no dependencies existed between the operations. In executing the above code, two of the Athlon 64’s integer execution units would go idle until the first line of code was executed.
Dependencies, such as the simple one that we talked about above, hinder the ability of modern day microprocessors to function to the best of their abilities. It’s like having three hands, but only being able to clean your room by picking up one item at a time; frustratingly inefficient.
Facebook
Twitter
RSS
70 Comments
View All Comments
ceefka - Thursday, March 17, 2005 - link
Rambus'RevengeLocut0s - Thursday, March 17, 2005 - link
Great article Anand!! Yeah I actually get to bring my Comp150 knowledge to bear in reading this article! If this had come out 6 months ago I would have been totally lost. It will indeed be interesting to see what headway Cell can make, however unfortunately as Anand alludes to the x86 architecture is just too heavily entrenched for anything to budge it except the Big 2 (AMD and Intel). I can't wait to see what type of power the Playstation 3 will have though, and especially how that power will be utilized in games. I bet there will be some jaw dropping graphics awaiting us there. That is if Cells limitations don't hold back lazy game developers and lead to a string of mediocre games punctuated by a few amazing titles made by independent developers who really care to utilize the architecture. Didn't the Playstantion 1 suffer something similar?knitecrow - Thursday, March 17, 2005 - link
The real world technology article on the cell, states that it gives up single thread performance in favour of runing many parallel threads. That sounds like a terrible difficult processor to development games for.I for one think it will be easier to put the burden on the hardware rather than on the software side.
Can we see another repeat of PS2? Technically impressive, but hard to code for.
JarredWalton - Thursday, March 17, 2005 - link
11 - I think the point is that games tend to use certain functions of a CPU much more frequently, while general business/office applications make use of a wider range of generic operations. I understand your complaint, as office applications generally don't need a lot more power than about 1.5 GHz at most. However, the key of the statement was the "general purpose microprocessor" and not the "very powerful" part.AnandThenMan - Thursday, March 17, 2005 - link
WAIT. What the flock does this mean?"Performance in business/office applications requires a very powerful, very fast general purpose microprocessor, but performance in a game console, for example, does not."
WHAT??????? Hello?? So an office app like Word needs a very powerful processor, but a game console does not? I beg to differ. I suppose it depends on how you define "business/office application" but I think that statement is WAY off. I know several current office applications that will limp along on a pentium 133, but no current game has any hope on the same CPU.
tipoo - Wednesday, July 30, 2014 - link
It was clear to me that meant console CPUs didn't have to be as general purpose and brute force powerful in every regard - they can get away with being more specialized, and suck at general work, but still fast for game specific code.Googer - Thursday, March 17, 2005 - link
When are they coming out? Anyone know of a release date?jeffbui - Thursday, March 17, 2005 - link
#4, I do. Heh.I've been waiting for this article forever.. thanks!
JarredWalton - Thursday, March 17, 2005 - link
Interesting stuff. The Playstation has always been something of a pain in the rear to program. PS1 went it's own way, and PS2 did the same. PS3 and Cell seem ready to pave new roads into the "OMG this is really complex" land of programming. I'm glad I've given up serious programming.... :)Googer - Thursday, March 17, 2005 - link
In soviet russia cell processor controls your mind.