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."

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 [ibm.com], if you want ;)

here's the real article...

[advocate_one]

Using advanced compiler technology to exploit the performance of the Cell Broadband Engine architecture [ibm.com]

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/ [berkeley.edu]

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 [berkeley.edu]
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:Sadly, not a lotta FPU hardware.

[Frumious Wombat]

They have, although outside of certain implementations of double-complex, 64-bit double-precision (REAL*8 to Real Programmers) is enough.

Those machines are Cray Vector Processors, MIPS R8K and later, DEC Alpha, HP/Intel Itanium, IBM Power 4/5/n, IBM Vector Facility for the 3090, etc.

Notice how many of those you see every day, and how many fewer of those you can still buy.

Yes, unfortunately, you are that tiny a proportion of the world pop. I had hoped by this point that we'd have Cray Vector Processors on a chip, or integrated into the base chipset (like the old Proc/Math-CoProc combos), or be running EV10 Alphas on our desktops. Unfortunately, double-precision floating point benefits so few people that it's not worth it from a design standpoint to optimize the processors around it. The R8000 was a good example of this; incredible FP for the time, but terrible integer (early Itanium-2 falls into this category as well). So, it crushes numbers like mad in the background, but your word processor, etc, are no faster and possibly slower than the previous generation, less expensive processor.

Just a couple of years ago my boss commented that we had problems in quantum chemistry which were still more time-effective to solve on mid-90s Crays than modern MPPs, because the algorithms vectorized easily but didn't parallelize. Some of them have been fixed by now, and alternatives found for others, but there are a lot of problems (by the standard of scientists) that would benefit from having a processor optimized for double-precision ops. Unfortunately, by the standards of the cell-phone-camera wielding email junkies, those problems are an invisible subset of the things you do with a computer. Ergo, good enough for home entertainment and PowerPoint, less than ideal for scientific use.

Thankfully Power5 and Itanium will be around for a few more years.

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...

Re:Sadly, not a lotta FPU hardware.

[Anonymous Coward]

A 32-bit Windows machine actually has 80-bit floats. The 32 bit are the address size, nothing to do with
FP.