Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
More registers in modern day CPUs
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-12-02 (10:14)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] OCalm on Sony PS3 (was Re: More registers in modern day CPUs)
> I have recently compiled OCaml 3.10 for the PS3 running Yellow Dog Linux.
> Seems to work fine, but I haven't tested it rigorously (and at this
point, I
> wouldn't even know how to test it ... um ...what's the opposite of
> "rigorously"? ... non-rigorously?)

I confirm that OCaml compiles correctly on the PS/3 with YDL.  The
native-code compiler works fine (in 32-bit mode) provided it's
configured with  -host powerpc-unknown-linux.  (Autodetection reports
powerpc64-unknown-linux, even though the default compilation mode on
this distro is 32-bit; I'll hack the configure script to work around
this issue.)

Of course, the generated code runs on the PPC core of the Cell
processor, not on the SPU cores.  Performance is unimpressive: about
1/5th of that of a recent Intel Core2 processor.

> I'd also be interested in any ideas for starting to explore
whether/how the
> Cell BE's power can be exploited using OCaml (hopefully simple ideas
at the
> outset, I'm a newb on several fronts here).

The SPU cores only have 256 Kb of local memory, so there is no hope to
run a Caml run-time system on them.  For some applications (linear
algebra, bignums), it might be possible to link with C libraries that
offload work to the SPU cores.

A more general but extremely difficult approach is two-level
programming, where the Caml program, running on the PPC core,
generates programs in a simple data-parallel language which is then
compiled on the fly to SPU code.  Such an approach could also target
graphics coprocessors (the "GPGPU" approach).  But I have no idea what
such an intermediate language would look like.

- Xavier Leroy