"Vincent Diepeveen" <[EMAIL PROTECTED]> writes: > ----- Original Message ----- > From: "Andrew Shewmaker" <[EMAIL PROTECTED]> > To: "Vincent Diepeveen" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[email protected]> > 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Beowulf mailing list, [email protected] To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
