IBM to use Cell in Blade Servers

taskforce writes "IBM announced on Wednesday that it would be putting versions of its Cell processor inside its increasingly popular low-power blade servers by this summer. From the article: 'For Cell to gain wide acceptance, IBM needs to spur outside programmers to write software that takes advantage of Cell's prowess. That could prove more challenging than usual because Cell's architecture is so different. IBM hopes this summer's release of the Cell-based servers kick-starts work by third-party programmers.'" Also covered in a PCPro article.

Comments

Where have I heard this before?

[Jordan Catalano]

That could prove more challenging than usual because Cell's architecture is so different. IBM hopes this summer's release of the Cell-based servers kick-starts work by third-party programmers.'"

Deja vu?

Re:Where have I heard this before?

[John Whitley]

Deja vu?

Nice quip, but the realities of the situation are completely different. My take on EPIC nee IA-64 when it was first publicly announced was surprise at an architecture that actually encouraged ultra-complex processor control logic. This, when prevailing trends tended to find ways to manage or reduce that complexity, or at least provide unambiguous chip-compiler synergy. Put another way, Intel made design choices that made the hardware itself very challenging to build and properly synergize with a compiler to achieve high total performance. Intel had certainly shown their chops at this sort of high-complexity chip controller design in the x86 line, but the move still seemed brazen from an outsider's perspective. History now shows that they certainly had trouble going down that path...

Cell, however, is basically a bog-stock PowerPC with DSP engines at its disposal. Think Altivec/MMX/SSE type units on steroids. This approach provides computing power that isn't applicable to all tasks, but is generally proven to perform well for applications that require high performance mathematical processing. Incidentally, that's precisely the target market that IBM's stated they're after with Cell-based servers. Moreover, Cell's scalability model and hardware complexities are much more managable.

To really leverage Cell's power from the software side will require some or all of 1) good compiler and toolchain support, 2) good library support, and 3) dedicated development effort for the specific application. IBM has the expertise and motivation to provide 1 and 2, and developers in the supercomputing world tend to get really good at 3. When your *highly optimized* supercomputer app may take on the order of a year to run, big emphasis tends to be put on making it run fast. Months of work to save years of time.

It still remains to be seen how this effort will play out in the marketplace, but variants of Cell's basic approach are working right now in many, many devices.

Noteworthy Information

[gasmonso]

Take a peek at http://www.research.ibm.com/cell/patents_and_publi cations.html to see the patents and whitepapers for cell technology. One interesting point is the Online Game Prototype white paper on there.

http://religiousfreaks.com/

Sun to use new chips

[db32]

Sun Microsystems has decided to include the Gohan chip to combat IBM's Cell chips.

How about a free optimizing compiler

[mi]

a free optimizing compiler, that takes advantage of the architecture, would do wonders...

It being command-line compatible with (or simply a back-end of) an existing compiler like gcc is even better.

Add a port of a good OS, and your platform is suddenly incredibly attractive to developers.

Re:How about a free optimizing compiler

[MaestroSartori]

The main problem, I suspect, is that general purpose code just doesn't run very well on it. You really need to optimise for each application, to tune how you handle your data and what algorithms you use in order feed the Cell properly if you want to get the most out of it.

Re:How about a free optimizing compiler

[ajs]

And of course, optimizing in that way is probably analogous to the halting problem, but that doesn't mean that a good general-purpose back-end for GCC could not be written. History teaches us one thing about specialized hardware that we should never forget: the average user of your hardware is going to need to have VERY LITTLE of their code hand-tuned for it. For example, let's say that this hardware tends to be very good at encryption. Your average user would likely be running a Web server or some other sort of networking technology, and almost NONE of that code cares about the 10-100 hand-tuned routines in OpenSSL that you wrote for this platform.

Get a good compiler and general-purpose OS up and running fast (which, by the way, I'm sure IBM is doing), and you'll see many more people writing special-purpose code where they need it.

Re:How about a free optimizing compiler

[Anonymous Coward]

There is a free GCC compiler for Cell. And Linux. And you can get a free simulator to run it on. All at http://www.ibm.com/developerworks/power/cell

Re:How about a free optimizing compiler

[Tune]

First, as others have already commented, a gcc backend is already available and Linux runs on Cell.

Second, optimizing compilers tend to optimize only small parts of linear code. Simply put, this comes down to filtering binaries and replacing inefficient code sequences by more efficient ones. Depending on the quality of the compilercore, this typically gains a few percent, occasionally some 25% but that's nowhere near what Cell could offer, namely (theoretically) 800%.
The problem is refactoring the problem to run in
- small chunks,
- independently (parallel)
- and on a specialized processor.
A compiler can help only modestly with the last point. In any non-trivial case, this means reanalyzing the problem and reimplementing the solution from the start, making different tradeoffs. That is why people say Cell is difficult.

IMHO, the benefits of code optimization will be close to irrelevant for almost any successful application on Cell over the coming years. And while Moore's law has provided us with bigger and faster hardware, we programmers are still mostly empty-handed when it comes to program translation for parallel architectures.

We need a paradigm shift, not an optimizing compiler.

Linux on Cell

[morgan_greywolf]

Considering they've already got Linux on Cell and a proposed model for making userland apps to take advantage of the SPUs, and have had these since last summer, I wouldn't be surprised if some open source code is already in the process of being ported.

Anyone know of any specific server apps?

cell cells itself

[digitaldc]

Juhi Jotwani, IBM's director of Blade Center and xSeries solutions, holds the company's new Cell processor during a presentation yesterday in New York.

She said, "Come on, juh know jouwant it!"

Sun has 'em beat

[AKAImBatman]

As I understand it, the various pipelines of the Cell chip tend to be more specialized than the Coolthreads technology Sun is using on their new T1 processor. However, even with 32 full-blown pipelines, Sun is also concerned about whether their chips will be put to good use or not.

I'm not quite sure what IBM is planning to do, but Sun has started a contest to see who can build the coolest program that takes advantage of their new Coolthreads technology. The prize is a cool $50,000, so Sun seems to be serious about this. The results of the contest may very well prove whether the new parallel technologies have a future or not.

Re:Sun has 'em beat

[Anonymous Coward]

The prize is a cool $50,000, so Sun seems to be serious about this.

If Sun were really serious, they'd put a $500,000 team on it to develop something themselves. Paying for 1/3 - 1/2 a man-year of development is not that serious.

Re:Sun has 'em beat

[Zantetsuken]

Especially when IBM's already setting the groundwork for Cell to be used in supercomputers (for seismic activity, nuclear warhead simulations, ect), rendering 3D MRIs (reportedly, current image rendering for this is done on Intel Pentium 4s and takes about 4 minutes, when they did the tech demo of it on a Cell platform, it took about 20 seconds).

Re:Sun has 'em beat

[ArbitraryConstant]

"As I understand it, the various pipelines of the Cell chip tend to be more specialized than the Coolthreads technology Sun is using on their new T1 processor."

Yes. A Cell's SPUs are not PowerPC processors, so you can't run the same code on the PowerPC front end as you do on the SPUs. Not only that, but Cell and Niagara are designed for totally different things. Cell is designed for floating-point intensive apps with pretty poor general purpose capabilities, while a Niagara has 1 floating point unit shared between all 8 cores and 32 threads but they're all good at the branchy sort of thing servers ususally run.

I think these Cell servers will be more useful for things like render farms, They'll be essentially useless as generic servers for web or database duty.

Who woulda thunk it?

[d3ac0n]

Blades in Cells are usually a Bad Thing. Apparently Cells in Blades are a good thing! Go figure...

Your organs are specialized, too.

[Orrin Bloquy]

It's a hell of a paradigm shift for programmers to go from writing code that targets one CPU to code that deliberately splinters tasks across a bank of specialized processors.

It's fun to bash the Cell as a general purpose CPU when no one has actually suggested it's designed for that.

All of the above being true, it remains to be seen what gains IBM's POWER/Cell system actually offers above present architectures -- RISC was the next big thing, too, until Intel internalized part of it into the x86 architecture.

Flyover landscape graphics demos are a shopworn rabbit pulled out of a threadbare hat: convert fractals into craggy vertical displacements with extremely primitive lighting/mapping. Show me an architecture that can *realtime* render Incredibles-caliber cloth/hair simulations and I'll get a hard-on while ATI and nVidia executives slit their wrists.

Re:Your organs are specialized, too.

[ivan256]

You used them as programable DSPs. The CPU couldn't actually do the hard work fast enough... The chip did the 'hard' work, and they just made the CPU do more work than a full modem.

PS3 release date?

[nutshell42]

This probably means that the PS3 will either actually make its "spring" release or that it is hampered by problems with the Blu-Ray drives/disks instead of a Cell shortage because otherwise I couldn't imagine that Sony would allow IBM to use even one Cell for something that's not a PS3 for the first 3 months.

Re:PS3 release date?

[SetupWeasel]

There is always the chance that the RAM, GPU, Blu-Ray drive, or something else would end up in short supply.

My guess is finished software.

Re:Increasingly Popular?!

[psbrogna]

Marketing people are quick to describe the 0 to >0 transition as "increasingly popular". Of course the rest of the world considers it statistical noise. : )

I work in blade development.

[Thaidog]

We've had blades with Cell cpus on them for quite a while. They're a lot different than any other architecture... resembling the pSeries layout more-so than others. One thing I don't like about the prototypes is that the Cell cpu's along with the bga memory they use are fused directly to the logic board. They're were a few pictures released to the public about a year ago on the Register but I can not find them now. Other than that they are seriously fast and very clusterable.

Re:I work in blade development.

[fitten]

They're a lot different than any other architecture...

Actually, they are similar to a number of DSPs and other discrete solutions from the past. For example:

The TMS 320DM64x series of DSP from TI which has an ARM9 and a number of DSPs on it.

The TMS 320DM54x and 55x series of DSP from TI which has an ARM7 and a number of DSPs on it.

And a descrete version in the CSPI MAP 1310/11 which had a PPC and multiple multi-core DSP chips on it as early as 1997.

Smaller blade chassis?

[killtherat]

IBM has opened the spec for their blade chassis design. Does anybody know if somebody is trying to make a 'desktop' blade chassis? Rather then buying a huge box that holds 14 blades, something that might only hold two.
This doesn't mean make a desktop out of a blade, because as I understand it, so far the JS20s (IBMs PPC 970 blade) don't even have video cards. You have to set them up over the serial port, and run them over the network.
But does anybody have a development sized unit you don't need a server rack and new power circuits for?

Re:Smaller blade chassis?

[ivan256]

Portable development units come mounted on their side in a 19" enclosure with a handle on top, semi-attractive looking trim pieces, and appropriate power supplies and cooling on the inside. They cost about three times what you'd pay for a standard rackmount production model.

Re:Exciting

[Anonymous Coward]

When I'm done, I pull it out and play.

i didn't need to know that.

Cell and T1 not targetting the same space

[raftpeople]

Sun's new processor is designed for many-connection business server applications. Web stuff.

The Cell is designed for image processing and other high-volume number crunching.

The design decisions both companies made were heavily influenced by their target markets for these specific processors, and those target markets are very different.

These are apples and oranges.

Re:Sun to use new chips: DragonBall

[Tolookah]

They can't use that name, freescale (motorola) already has it, and killed the line
http://www.freescale.com/webapp/sps/site/taxonomy. jsp?nodeId=0162468rH3YTLCvL2v

if you knew this, then fwoosh went the joke over my head

Good point. Unfortunately ...

[vlad_petric]

It's *very* difficult to get a compiler to exploit this kind of parallelism. Unless you're doing scientific Fortran loopy code, where it's much easier to do things like automatic vectorization/parallelization, it's basically almost impossible for the compiler (out of curiosity, try to use the automatic openmp parallelization feature within Intel C Compiler on standard C/C++ code; the results will likely underwhelm you). Unfortunately, even if you do have scientific code, the slave processing units only do simple precision (IIRC).

In my opinion, this thing will run well games, but that's about it. I've seen so far 2 presentations by IBM about the Cell processor (at (micro-)architecture conferences). Both times, the question on everybody's mind was "How do you program these things?". The answer was pretty much a hand-wavy "oh hmmm, well, blah blah blah manual"

Re:Good point. Unfortunately ...

[be-fan]

Cell's peak theoretical performance is 25 gigaflops, derived by taking the product of the clockspeed (3.2 GHz), and the number of operations per cycle (8). In reality, this figure is highly optimistic. Each SPE only has a single floating-point pipeline. The 8 operations/cycle figure is derived by counting a 4-element single-precision multiply-accumulate as 8 total operations. Moreover, when doing double-precision operations, it takes an additional 5x speed hit, since they must be performed in multiple clock cycles. That results in Cell's theoretical performance for double-precision code being a total of 10x lower (according to IBM), or around 2.5 gigaflops per SPE. At 10 gigaflops per chip, that's still relatively impressive, compared to the 5 gigaflops per chip a dual-core Opteron (2.4 GHz) can handle, but the actual performance of a Cell chip is going to be a lot less than the actual performance of the Opteron.

Understanding why requires a bit of understanding of chip-design, but the basics are simple. The Cell SPE basically has four things working against it:

1) No dynamic branch prediction. This means that when the Cell SPE encounters a branch instruction, it will always assume the backwards branch is taken. This works fine for loops, where its good to assume that the branch at the end of the loop will jump back to the beginning of the loop, but doesn't work well for anything else. If the guess is wrong, then the CPU pays an 18 cycle penalty while the pipeline is flushed and the correct branch path is followed. The Opteron, on the other hand, keeps track of the history of each branch. It can then make a much better guess about which way the branch will go, and avoid paying a penalty for guessing wrong. Since the Opteron's pipeline is shorter, this also means the penalty for an incorrect guess is much less (around 12 cycles). The net result of all this is that if your code has lots of short loops (static branch prediction always mispredicts the iteration that exists the loop), or a lot of complex control flow, Cell's SPE's are going to lose a lot of their theoretical performance since many cycles will be wasted on mispredicted branches.

2) Very high latency for instructions and loads. In Cell, the floating-point latency is at least six cycles, and the load latency from the local store is at least 6 cycles. For Opteron, its 4 cycles and 3 cycles, respectively. Basically, the instruction latency tells you by how many clock cycles you must seperate dependent operations. Eg: on an Opteron, you can issue a memory load, and assuming an L1 cache hit, you can issue an instruction that uses the loaded register 3 cycles later. If you have no instructions you can issue until that load is completed, then you just issue nothing that cycle and lose some of your potential throughput. Since the SPE's latencies are much higher, there is a much higher chance that you won't have any non-dependent instructions to issue on a given cycle, and must waste that cycle.

3) A very specialized memory model. Cell's SPEs can only directly address 256KB of local memory. If you have data bigger than that, you have to manually shuffle it in and out of that local memory. The latency for doing this shuffling is extremely high on Cell. This means that in code that accesses big data sets, if you can't effectively partition your data sets, you'll waste a lot of time shuffling things in and out of memory.

4) No out-of-order execution. Modern CPUs like an Opteron will rearrange your instructions to get around the instruction latencies I mentioned earlier. It'll look ahead in the code stream a couple of dozen instructions to find non-dependent ones that can be issued while waiting for other ones to finish. Cell won't do that. If you have an ADD in your code, and then right after you have a MUL that uses the results of the ADD, then Cell will merrily wait 6 cycles waiting for the ADD to finish, even if right after the MUL you have another ADD that doesn't need the results of the first one. This places a lot of burden on the c

But wait

[Pakaran2]

Won't the Cell reception be poor inside the metal cabinets?

*looks bright*

Re:hardware abstraction?

[ivan256]

you hand optimize (and design) your program for the cell.

Every parallel architecture I've ever programmed for had nice APIs for offloading and directing tasks to the various available processing units. There shouldn't be much 'hand-optimization' involved in the sense you're implying.

Developers who write code that takes advantage of GPUs in modern gaming PCs are already familliar with this style programming, and the ones that understand the architecture instead of memorizing the APIs or program out of a cookbook should have no trouble adapting.

Re:Big Difference Between Itanium and Cell

[Skowronek]

Itanium offers such a giant increase in performance (for some applications) compared to rival RISC products that you will see people investing time and money to take advantage of it. In addition, with Intel, SGI and HP all with product plans and thus the related volume and eco-system surrounding development tools, etc., I think the Itanium is positioned far better than Alpha to succeed.

D'oh.

Re:Big Difference Between Itanium and Cell

[ShadowFlyP]

Actually, the bigger difference is in how the architecture changed. Cell processor is more along the lines of multi-core DSPs. The instruction set is different than general computing cores and there are many of them. The key is that these cores are disjoint. You can run one application on one core and another application on another core.

The Itanium is different than this in that it required instructions to be passed to the CPU as "bundles". Any of the instructions in a bundle could be executed in any order, but these instructions were all from the same application. Thus, in order to extract speed from the Itanium, the compiler was forced to extract parallelism from within functions. This is very difficult since most programming is fairly sequential. The Cell, on the other hand, allows you to execute different tasks and so puts this control back on the programmer instead of extra work for the compiler.

Itanium was (is) a great idea from compiler theory perspective, but doesn't work out all that well (yet) in the real world.

IBM already has these tools available

[raftpeople]

To the programmer, communicating with the SPU is abstracted to file i/o operations. Go check out IBM developerworks pages for lots of info.

Re:hardware abstraction?

[2megs]

Developers who write code that takes advantage of GPUs in modern gaming PCs are already familliar with this style programming,

But you can probably count on your fingers the number of developers who are using GPUs for anything other than rendering pixels, or at most some simple vectorizable simulations like water or cloth.

Taking an arbitrary program and turning it into something that would run well on a GPU (or a Cell SPU) usually requires a significant redesign of the algorithms and data structures as compared to what you would naively and straightforwardly do in C...or it won't get anywhere near peak performance and may even run slower. It's certainly possible to do, but you won't be re-using any of that originally written code, and it's a different way of thinking from what 95% of programmers are used to. I'm speaking from experience as someone who earns his living by being in the remaining 5%. :)

As the original poster said: you hand optimize (and design) your program for the cell.

Why SPEs?

[Guspaz]

Why go with SPEs anyhow? The whole problem with coding for the Cell involves the differences between the PPE and the SPE. The SPE doesn't have branch predictors, making it virtually useless for any sort of flow control.

Why didn't IBM just pack in a lesser number of PPEs? The PPE already seems to be a very lightweight general purpose processing core, unless I'm missing something. It is about the same size as an SPE. So why not just put 9 PPEs on a Cell chip instead of 1 PPE and 8 SPEs?

If you had 9 PPEs on the chip, any multithreaded code (servers for example) would see massive benefits without having to rewrite it to try to find aspects of the program that could run on what is effectively a DSP. While everybody else was fooling around with 2-core processors, they'd have a 9-core processor on the market. Sure, slower per-core, but 9 of them, with that number going up in the future.

Or am I missing something here?

compute per silicon-area/watt/$

[Soong]

PPEs are bigger. Also, a dedicated slave processor doesn't have to worry about interrupts and context switches and OS crap, it can spend all its cycles on number crunching. Cell SPEs are all about moving large amounts of data and doing a whole lot of compute on that data. They're simpler and more efficient at what they're designed for.

Re:Big Difference Between Itanium and Cell

[DoofusOfDeath]

You're close to correct. The Cell processor does have a bunch of cores that are basically DSPs (no virtual memory, etc.) BUT there's also another core that's basically a full-blown Power processor. That core is meant to rule the others.

So while you do still have to program differently for a cell with 8+1 cores than you would for a computer with 9 Power processors, it's still not like being stuck with just 9 DSPs.

"multi-core DSPs" WITH CRIPPLED FPUs!!!

[mosel-saar-ruwer]

Actually, the bigger difference is in how the architecture changed. Cell processor is more along the lines of multi-core DSPs.

Standard computer graphics are RGB color at 24-bits per pixel [2^24 = 16777216], i.e. about 16 million colors.

Standard thinking in the graphics bidness is that: If our triangles will only be displayed in 24-bits worth of color, then why do we need to perform triangle-arithmetic in anything higher than maybe 32-bits worth of floating points?

Hence floating point calculations are 24-bit in the ATi world, and 32-bit in the nVidia and Playstation3/Cell world.

Boy, I hope they're upping that floating point number for these "server" chipsets, cause 32-bit single-precision floats are essentially worthless for even something as trivial as computing interest on a bank statement.

On the other hand, a "Cell" server CPU with a 128-bit FPU would be something to drool over. The problem, though, is that transistor counts on FPU's tend to increase as n^2, so each time you double the FPU bit-count [to 64-bits, then to 128-bits], your transistor count goes through the roof.

Re:"multi-core DSPs" WITH CRIPPLED FPUs!!!

[woolio]

Hate to break some painful news to you, but "24-bit" RBG refers to each color getting 8bits -- an UNSIGNED INTEGER value.

No floating point involved -- at all...

Now for 3D Graphics, coordinates may be represented in floating point. But during rendering, the values are converted to 8-bit integer values for Red, Green, and Blue components of each pixel.

And financial calculations are computed using INTEGER arithemetic....

A lot of things that might appear to require floating point, can often be implemented using "fixed-point" integer arithmetic (VERY accurately). They advantage of the latter is reduced hardware cost, increased speed, and lower power consumption.

Do you think a celluar phone performs the voice compression in floating point? Nope!

Two Tutorials

[GrEp]

IBM needs to release two SIMPLE tutorials if they want programmers to bother porting code specifically to the cell:

1. A cell program that solves linear equations Ax=b efficently using SPE's. This would help those with data intensive problems.

2. A cell program that speeds up depth first search (a la for SAT,GRAPH COLORING, MAX-CLIQUE) by using the SPE's. This would help those programming CPU intensive problems.

Re:Big Difference Between Itanium and Cell

[networkBoy]

Parent not funny, it's insightful!
-nB

Give me an ATX board

[mnmn]

They could come up with ATX or miniATX boards at real cheap prices, able to take your average DDR DIMMs, power supplies and IDE etc. Give it maybe 3 PCI slots... or 1 if its miniATX.

Sold for under $100, and theyre making money off it while spreading the love that will increase the developer market for the cell architecture.

It goes like this. Make a new architecture. Release a good compiler for free.. with awesome documentation and sample programs and libraries. Allow people to buy evaluation boards for low prices. Once you get people hooked enough, sell the chips themselves at high prices. Its the Microchip (tm) model. Their chips dont really do much for the high costs (compared to atmel, TI etc) but since everyone knows how to work them, they sell sell sell. Rabbit semiconductors however are trying hard to get into the market, and their dev tools are cheap. It'll take time.

IBM cant release a couple o PDFs and one tough software suite and expect the world to jump on it. Theres a reason why theres so much momentum behind the Power architecture, and the Cell is different.

If you can do threads, then you can do Cell

[tepples]

If you put the onus on the programmers, this chip won't get widespread acceptance.

If you can write a PC program that uses 10 threads, then you can write a program that uses the Cell processor's PPC and 7 DSPs. Trouble is that most computer science education in universities doesn't cover practical use of threads.

Tutorials 3 and 4

[dch24]

Having been a long-time reader over at the IBM forums, there are a lot of similar questions and answers going on over there.

There were a couple that would be really helpful:
1. An implementation of zlib for the SPE architecture, with a speed comparison to the PPE. (Hopefully, the SPE is very fast...)
2. Examples of direct SPE-to-SPE streaming.

Re:Big Difference Between Itanium and Cell

[rocketpig]

One Cell to rule them all, One Cell to find them, One Cell to bring them all and in the darkness bind them.