Understanding the Cell Microprocessor

Usage Patterns

Before getting into the architecture of Cell, let’s talk a bit about the types of workloads for which Cell and other microprocessors are currently being built.

In the past, office application performance was a driving factor behind microprocessor development.   Before multitasking and before email, there was single application performance and for the most part, we were talking about office applications, word processors, spreadsheets, etc.   Thus, most microprocessors were designed toward incredible single application, single task performance.

As microprocessors became more powerful, the software followed - multitasking environments were born.   The vast majority of computer users, however, were still focused on single application usage, so microprocessor development continued to focus on single-threaded performance (single application, single task performance).

Over the years, the single-threaded performance demands grew.   Microsoft Word was no longer the defining application, but things like games, media processing and dynamic content creation became the applications that ate up the most CPU cycles.   This is where we are today with workloads being a mix of office, 3D games, 3D content creation and media encoding/decoding/transcoding that consume our CPU cycles.   But in order to understand the creation of a new architecture like Cell, you have to understand where these workloads are headed.   Just as the types of applications demanding performance today are much different than those run 10 years ago, the same will apply to applications in the next decade.   And given that a new microprocessor architecture takes about 5 years to develop, it is feasible to introduce a new architecture geared towards these new usage models now.

Intel spoke a lot about future usage models at their most recent IDF, things like real time voice recognition (and even translation), unstructured search (e.g. Google image search), even better physics and AI models in games, more feature-rich user interfaces (e.g. hand gesture recognition), etc.   These are the usage models of the future, and as such, they have a different set of demands on microprocessors and their associated architectures.

The type of performance required to enable these types of usage models is significantly higher than what we have available to us today.   Conventionally, performance increases from one microprocessor generation to the next by optimizing single thread performance.   There are a number of ways of improving single thread performance, either by driving up the clock speed or by increasing the instructions executed per clock (IPC).   Taking it one step further, the more parallelism you can extract from a single thread, the better your performance will be - this type of parallelism is known as instruction level parallelism (ILP) as it involves executing as many instructions out of a thread at the same time.

The problem with improving performance through increasing ILP is that from one generation to the next, you’re only talking about a 10% - 20% increase in performance.   Yet, the usage models that we’re talking about for the future require significantly more than the type of gains that we’ve been getting in the past.   With power limitations preventing clock speeds from scaling too high, it’s clear that there needs to be another way of improving performance.

The major players in the microprocessor industry have all pretty much agreed that the only way to get the type of performance gains that are necessary is by moving towards multi-core architectures.   Through a combination of multithreaded applications and multi-core processors, you can get the types of performance increases that should allow for these types of applications to be developed.   Instead of focusing on extracting ILP to improve performance, these multi-core processors extract parallelism on a thread level to improve performance (thread level parallelism - TLP).

It’s not as straightforward as that, however.  There are a handful of decisions that need to be made.   How powerful do you make each core in your multi-core microprocessor?   Do you have a small array of powerful processors or a larger array of simpler processors?   How do they communicate with one another?   How do you deal with feeding a multi-core processor with enough memory bandwidth?

The Cell implementation is just one solution to the problem...