[Beowulf] Has anyone actually seen/used a cell system?

[Eric W. Biederman]

"Vincent Diepeveen" <diep at xs4all.nl> writes:

> ----- Original Message ----- 
> From: "Andrew Shewmaker" <agshew at gmail.com>
> To: "Vincent Diepeveen" <diep at xs4all.nl>
> Cc: <J.A.Delcorso at larc.nasa.gov>; <beowulf at beowulf.org>
> Sent: Monday, October 02, 2006 4:03 PM
> Subject: Re: [Beowulf] Has anyone actually seen/used a cell system?
>
>
>> On 10/2/06, Vincent Diepeveen <diep at xs4all.nl> wrote:
>>> Not wanting to sound too negative, but total nonsense concept.
>>>
>>> First of all this 'sequoia' claims to be a new programming language.
>>> Meaning it'll take a year or 30 until some good compilers for it are there,
>>> provided someone is going to support it.
>>>
>>> Which isn't going to happen.
>>
>> Like many new programming systems, it compiles to C.
>>
>>> The parallellization basically is based upon complex assumptions for
>>> programmers. So for programmers they don't actually make it easier than
>>> trivial parallellization is via C/C++ function calls.
>>>
>>> The sequoia parallellization basically is simplistically over for loops that
>>> a programmer himself can trivially parallellize too.
>>
>> Sequoia allows the same source to compile and run on systems with
>> very different memory hierarchies.  It uses MPI on clusters and DMA
>> on the Cell.  It also manages overlays on the Cell.  Do you consider a
>> portable runtime system that manages overlays and streams data
>> asynchronously trivial to implement?
>
> Which is my bottom line point. You'll need 1000 compiler programmers to get your
> language
> supported well.

Well I believe this 1000 compiler programmers number is quite high.
Certainly that isn't needed for a simple language like C.  One or
two man years is sufficient to write a usable and decent optimizing
C compiler.

> Even then, do you use pointers?
>
> If not: end of efficiency of your language.
>
> For complex algorithms, yes even some simple, C# and JAVA are factor 3 slower
> than C
> solutions, provided the C programmer is real good.
>
> Now of course Sun and Microsoft created big paper work to prove (based upon some
> console routines that print to the graphics card, so not processor based!) that
> their programming language is ok.
>
> But for applications that i write, which aren't dependant upon the console
> speed,
> it is simply factor 3.
>
> In some functions of course an even bigger factor, as the compilers do not
> optimize at hardware level.

You need to make a distinction here in the new language category.
If you build something that is a syntax helper like ratfor.  That
takes very little and can gain quite a lot.

If you do something like a Pascal -> C compiler where the only real
difference between the languages is the syntax you can do that pretty
easily and it won't see many problems.  It won't be very interesting
though, unless the new syntax is much better.

If you try something radically different and need to write language
specific optimizers then you are in trouble.  Unless the productivity
gains are huge the amount of time spent learning the language will
not be saved when writing and optimizing code in the language.

I agree that generally libraries are a much more practical thing to implement.

I don't know which category sequoia falls into I haven't read the paper,
the only way it sounds interesting to this conversation is that it has
some mildly interesting benchmark numbers associated with it.

At the moment I'm a lot more interested in packets per second and bandwidth
per second for future architectures then flops per seconds.  Cpu architects
understand how to push the flops per second of general purpose processors
quite high and are unlikely to develop amnesia when they have competition
who is just as able as they are.   Where the current challenge comes from
is how do you keep the bandwidth and I/O rates to the outside world growing
at an exponential rate.  Maybe big SMPs on a chip will help with this if they can
isolate most of the traffic inside them selves but I doubt it.

Eric