Re: 1teraflops cell processor possible?

On Fri, 28 Nov 2003 06:04:50 GMT, Andrew Reilly
<[EMAIL PROTECTED]> wrote:

>On Fri, 28 Nov 2003 00:03:01 -0500, Robert Myers wrote:
>> If you need to haul data a significant portion of the chip width to
>> use it once or twice, you're going to get killed on energy costs
>> relative to a true streaming architecture.  You can't program that
>> away.
>
>You *have* to program it away.  If your program only knows how
>to do one thing to each piece of data, then it doesn't matter
>how "streaming" the architecture is.
>
I have no idea what fraction of codes could be successfully rewritten
to exploit a streaming architecture, but if the architecture forces
you into the get it, do something, put it back mode, you can't program
that reality away.  If you *do* have a streaming architecture
available, you still have to figure out how to take advantage of it.
If that's your point, of course I agree.

>>>Legacy code and legacy coding practices exist.
>>
>> I don't know in what area you work or have worked, but HPC codes are
>> constantly being rewritten to accommodate new architectures.
>
>If HPC codes could be written to accommodate streaming
>architectures, then you'd already be seeing 100% FU utilisation
>on the existing commodity-processor-based MPP HPC systems.  You
>can get (close to) that for some benchmarks (linpack), but that
>doesn't seem to be the general case.  The problem is a software
>one (at least to a first order of approximation, and on todays
>hardware).
>
The Burger King in my hometown has a sign near the place where they
keep the french fries: "It's okay to waste french fries."  They'd
rather throw out french fries that are not at the peak of perfection
than have customers get turned off to one of their most profitable
menu items.

We need to start learning, "It's okay to leave execution units idle,"
in the sense that maximum exploitation of execution units is no longer
the desiteratum of computing.  Moving data around with the goal of
maximizing use of execution units is the computational equivalent of
selling stale french fries.

>My point is that it's all very well to extrapolate hardware
>costs out five years and reach certain conclusions, as these IBM
>guys have done, but if you still don't know how to get hardware
>in that shape to do what you want to do, then its not very
>useful, however energy efficient it is.
>
The Merrimac team is from Stanford, not IBM.  

A journey of 1000 miles begins with one step.  As long as all our
effort is aimed at processors built on processors that maximize the
wrong thing, that's where we will remain stuck.

RM