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

[Vincent Diepeveen]

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

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.

>> Further the optimization of sequoia simply doesn't happen. They assume
>> "kernel libraries" solve the problem. Interestingly it mentions 
>> explicitly:
>>
>> "if kernel libraries could be obtained, such as FFTW and the intel MKL 
>> for
>> PCs, or the IBM SPE matrix library for Cell, we call these libraries from
>> Sequoia leaf tasks".
>>
>> In short if some algorithm has not been implemented for sequoia, sequoia 
>> is
>> unusable.  Others may do the work as usual to promote sequoia.
>
> As I understand it, the leaf tasks can be written in C, Fortran, or 
> whatever.
>
> Saying Sequoia is unusable is like saying that MPI is unusable.

Let me quote the paper:

"we present sequoia, a programming language designed to .... "

So now you withdraw the claim that it is a programming language on its own?

Either claim it is an ANL, another new (programming) language,
or claim it is a library.

Don't claim both.

If it is a library which i can call *from* C code, such as CILK, then it 
isn't a programming language,
but i can use the efficiency of C code.

If it is an ANL, then face reality that it will never get anything.

MPI is not a programming language, it's a library you can use in many 
languages to transport messages between nodes.

Of course an ANL is going to fail anyway if you want to be utmost 
compatible, claiming something you created is so compatible that it works 
both for a CELL as well as for a cluster.

This is just too silly for words.

The biggest problem of most students when creating a program, is that they 
want to be overcompatible. Supporting everything.

Claiming sequoia is like that too, means you don't need 1000 compiler 
programmers, but 5000.
Because for each hardware a specific bottleneck is there, requiring a new 
implementation.
What works well at a CELL might not ever work fine on a gigabit ethernet 
cluster.

Vincent

 -- 
> Andrew Shewmaker