Octopiler to Ease Use of Cell Processor

Sean0michael writes "Ars Technica is running a piece about The Octopiler from IBM. The Octopiler is supposed to be compiler designed to handle the Cell processor (the one inside Sony's PS3). From the article: 'Cell's greatest strength is that there's a lot of hardware on that chip. And Cell's greatest weakness is that there's a lot of hardware on that chip. So Cell has immense performance potential, but if you want to make it programable by mere mortals then you need a compiler that can ingest code written in a high-level language and produce optimized binaries that fit not just a programming model or a microarchitecture, but an entire multiprocessor system.' The article also has several links to some technical information released by IBM."

Comments

Re:Hello, Itanium...

[Brain_Recall]

More familiar than you may think. Some of the first Itanium compilers were spitting out nearly 40% NOP's, which are simply do-nothings. Because the IA-64 is explicilty parallel, instructions are generated and bundled together to be executed in parallel. The problem is branches, which destroy parallelism since they can change the code direction. On average, there are about 6 instructions between branches, so, such a design is very costly since the memory controller will be stuck getting inscructions that are empty. Of course, speculation and branch-prediction is generally a good way to increase performance, but like many things on the IA-64, that's left to the compilier to figure out. These are some of the exact same problems with the Cell, although, I wish I knew how the instruction set was. If it's more like Itanium, then they got all of the problems of the Itanium. If it's more of a direct approach, they may be able to pull it of because of the work in multi-processor systems that are done today. But, they simply can't expect the "super-computer" numbers Sony keeps flashing around. It may be good on certain tightly coded scientific calculations, but when it comes down to real-world code, it's stuck to the stripped-down Power4 that is coordinating the Cells.

They didn't call it the Itanic for nothing...

No, it's there alright

[Daath]

Nah, it's there. Download it, if you want ;)

here's the real article...

[advocate_one]

Using advanced compiler technology to exploit the performance of the Cell Broadband Engine architecture

enjoy... :)

Check out William Kahan at UC-Berkeley.

[mosel-saar-ruwer]

What benefit does increasing the precision of floats to 128bits bring? 64bits are more than enough for 99.9999% and the remaining cases can be handled in sw emulation. You can still not solve (without massive growth of the error terms) an equation system described by a Hilbert-matrix using Gaussean-elimination no matter how many bits you make the mantissa.

Check out some of Professor Kahan's shiznat at UC-Berkeley:

http://www.cs.berkeley.edu/~wkahan/

In particular, look at the pictures of "Borda's Mouthpiece" [page 13] or "Joukowski's Aerofoil" [page 14] in the following PDF document:

How Java's Floating-Point Hurts Everyone Everywhere
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
WARNING: PDF DOCUMENT

As I understand it, the "wrong" pictures are computed using Java's strict 64-bit requirement; the "right" pictures are computed by embedding the 64-bit calculation within Intel/AMD 80-bit extended doubles, performing the calculations in 80-bits worth of hardware, and then rounding back down to 64-bits to present the final answer.

MORAL OF THE STORY: Precision matters. You can never have enough of it.

Re:Check out William Kahan at UC-Berkeley.

[greg_barton]

How Java's Floating-Point Hurts Everyone Everywhere

Gods.

This is eight years old, (1998) and has been fixed for five years.

FIVE YEARS. Join the 21st century, for god's sake.

java.lang.StrictMath

How long will people repeat this, even though it's been fixed for five years, in java 1.3? The latest beta VM is 1.6...