Cell-based Server Blade Demonstrated

slashflood writes "Only a few clients in a hotel room near Los Angeles had the chance to see the first Cell based server blade running Linux 2.6.11. 'We demonstrated the prototype to show that Cell continues to mature. The product is expected to have several times higher performance compared to conventional servers,' said an IBM engineer."

Comments

Re:Interesting quote from the article

[damiam]

Sony's 2TFlops number for the PS3 includes the NVidia graphics chip, which has an insanely high FLOPS count but isn't really useful for general-purpose computation.

Re:Very promising technology= investment opportuni

[soricine]

After you've read Blatchford's write-up, read this for a reality check:

http://arstechnica.com/news.ars/post/20050124-4551 .html

It uses such terms as 'hogwash' and 'wild-eyed and completely unsubstantiated claims'. Ouch.

Re:I'm just curious

[Michael Hunt]

'factoring prime numbers'?

You mean deriving the factors of products of primes, right?

Re:Deep thought...

[bersl2]

I saw some code flying around on a mailing list somewhere. This looks good enough:

http://seclists.org/lists/linux-kernel/2005/May/26 57.html

Re:Now we just need to ask it tough questions!

[MyNymWasTaken]

I wonder if anyone knows how close we are to the power of the human brain yet.

How do measure the computational power of the human brain?

Here's a 6 year old napkin calculation.

They give a figure of 10^8 MIPS. Figure 1:8 for a MIPS:MFLOPS ratio. So ~13 TFLOPS.

The IBM Blue Gene/L is the current record holder at 135 TFLOPS. That puts it at the power of 10 human brains if that napkin calculation has any validity.

For average consumer computers...

The ordinary computer of Aug. 2004 performed 18,000 MIPS. Ref

Human brain power is ~12.44 Moore's law cycles away from that point. That gives 19-25 years.

So, your computer should be more powerful than your brain by 2030.

It's not Sony's hype

[Anonymous Coward]

IBM designed the Cell

Re:Deep thought...

[megan_of_wutai]

They already have.
One of the more interesting posts: http://lkml.org/lkml/2005/5/13/218
Arnd Bergmann works for IBM, btw.

Carmack has tried...

[Namarrgon]

Carmack explored threading the Quake3 engine pretty thoroughly - and concluded that it really didn't help much, due to the nature of the problem - high-bandwidth communication between threads.

Some types of computing problems (e.g the compositing app I work on) multithread very well, and some just don't.

It's possible Q3A might thread better on a Cell, due to high bandwidth between SPEs - but then again, he was using a the second thread for vertex processing, which is done by the GPU these days anyway.

Re:Great

[Anonymous Coward]

How about NetBSD?

Porting Linux to new archs tends to be fast, but incredibly sloppy compared to NetBSD.

Re:Very promising technology= investment opportuni

[jsn13]

reality check, hmm. so, where exactly is `reality' there? the article doesn't say a single word about the Cell processor architecture. author's just being nitpicky about Blachford's analysis.

well, let's be nitpicky too, then.

• 1st paragraph summary: "Blachford sucks at understanding of basic computer architecture". ok, let's see.
• 2nd p. summary: "estimated benchmarks are all speculative (and, thus, it's hogwash)". oh great, mr. Hannibal probably knows how to get real (non-speculative) benchmarks for Cell. and nevermind Blachford says: "This is something of a "calculated guess", again based on the theoretical maximum computing power being achieved (in 4 Cells). It makes a lot of assumptions which may be in error so I will not be the least bit surprised if this figure is miles out...".
• 3rd p. summary: "Blachford talks about `no cache' and `local memory', but actually `local memory' == `cache'". someone obviously missed the detailed explaination in Blachford's article about exactly how local memory in Cell is different from cache (with terminology issues explicitly covered).
• 4th p. summary: "Blachford also declares that the longstanding problems inherent in code parallelism and multithreaded programming are now solved, because the Cell will just miraculously do all this stuff for you via fancy compiler and process scheduling tricks.". from what i can see, Blachford mentions the word `compiler' in his article exactly once: "Cells will have compilers just like everything else". and Blachford also writes:

  The Cell Compiler Will Magically Make The Code Parallel This is not true and I didn't say this. You still have to break up problems into software Cells. I still cannot figure out why people think I said this.

oh well. Anyway, I could go on, but I'll stop here. You get the idea.

Re:OS X on Cell?

[Anonymous Coward]

"while the Cell is still using a basic G5 at its core"

The Cell power core is not like G5 at all, it in generally slower than the current G5s. It has fairly high frequency but it is an in-order CPU.

Re:show us the numbers

[argent]

What I care about is how fast the thing runs when I run normal code compiled with a normal compiler and (possibly hand-optimized) numerical libraries.

It'll run them exactly as fast as any other PPC 970 core. As far as I can see from the information that's been released so far, to use the coprocessors at all you'll need to redesign your application around an asymmetric coarse-grained parallel processing model, with explicit memory management to feed data to the shared RAM the SPUs have access to.

Re:Uhhh

[TheRaven64]

The reason SIMD did not really revolutionise anything on x86 is that MMX sucked, and sucked badly. It added extra registers, which could not actually be used 90% of the time (just adding half a dozen GPRs to the x86 ISA would have given more of a speed boost than MMX in many cases, as x86-64 has shown). It required a context switch (very expensive on x86) to use, and it could not be used at the same time as the regular FPU (as I recall). Oh, and I seem to remember that it only worked with very small vectors, and only integer instructions.

In short, MMX was a lame duck, but was hyped to a huge extent by Intel. The shortcomings of MMX have (at least partially) been addressed in subsequent x86 vector units, but by that time it was too late. If you are doing scientific computing, and can target your code to a particular CPU, this is fine, but who[1] has the effort to optimise code for MMX, SSE, SSE2, SSE3, 3dNow!, etc?

On the Mac, AltiVec was the first vector unit to be released, and was of a very high, proven, quality. Subsequent chips have retained compatibility with exactly the same vector ISA, meaning that everything written for a G4's vector unit will gain the same benefit on a G5[2].

[1] Microsoft, in DirectX, and a few other people, but not very many.

[2] Clock-for-clock, I believe the G5's vector unit performs slightly worse than the G4's, however G5s usually come with higher clock speeds, so it makes little real-world difference.

Old News

[modular_forms_boy]

The patches were being sent to the Linux Kernel Mailing List a month ago for integrating kernel support for the Cell Processor. Just check the LKML Post from IBM-Deutschland employee Arnd Bergmann.

IBM doesn't tend to release code to the public until it's been through a long approval process ;-)