From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 69378BC69 for ; Tue, 4 Dec 2007 03:29:43 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADtKVEfAXQImh2dsb2JhbACPTgEBCAop X-IronPort-AV: E=Sophos;i="4.23,246,1194217200"; d="scan'208";a="6444509" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 04 Dec 2007 03:29:43 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id lB42Tg5g021521 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 4 Dec 2007 03:29:42 +0100 X-IronPort-AV: E=Sophos;i="4.23,246,1194217200"; d="scan'208";a="5222859" Received: from smtpoutm.mac.com ([17.148.16.76]) by mail1-smtp-roc.national.inria.fr with ESMTP; 04 Dec 2007 03:29:42 +0100 Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id lB42TeTL006309 for ; Mon, 3 Dec 2007 18:29:41 -0800 (PST) Received: from [192.168.8.101] (c-24-218-151-219.hsd1.ma.comcast.net [24.218.151.219]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id lB42TcmI022195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 Dec 2007 18:29:39 -0800 (PST) Message-Id: <82B20B5F-0A52-4183-9C74-BE54C0F607C4@mac.com> From: Gordon Henriksen To: caml-list@inria.fr In-Reply-To: <47528593.9060106@inria.fr> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] OCalm on Sony PS3 (was Re: More registers in modern day CPUs) Date: Mon, 3 Dec 2007 21:29:38 -0500 References: <875c7e070709060755r1d0d099ds30a25ea78d0fd85a@mail.gmail.com> <46E01A27.1070207@janestcapital.com> <509223F0BF55E74FA1247D17207E7A0C01D75893@orsmsx419.amr.corp.intel.com> <87r6lb90tw.fsf@linux-france.org> <46E046DF.5010103@univ-savoie.fr> <46E04B85.1020004@naughtydog.com> <13858952.post@talk.nabble.com> <47528593.9060106@inria.fr> X-Mailer: Apple Mail (2.915) X-Miltered: at discorde with ID 4754BB96.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 fronts:01 run-time:01 algebra:01 bignums:01 two-level:01 statically:01 openmp:01 ocaml:01 sony:98 2007,:98 outset:98 wrote:01 caml-list:01 linear:02 On Dec 2, 2007, at 05:14, Xavier Leroy wrote: >> I'd also be interested in any ideas for starting to explore whether/=20= >> how the Cell BE's power can be exploited using OCaml (hopefully =20 >> 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 =20= > to run a Caml run-time system on them. For some applications =20 > (linear algebra, bignums), it might be possible to link with C =20 > libraries that offload work to the SPU cores. > > A more general but extremely difficult approach is two-level =20 > programming, where the Caml program, running on the PPC core, =20 > generates programs in a simple data-parallel language which is then =20= > compiled on the fly to SPU code. Such an approach could also target =20= > graphics coprocessors (the "GPGPU" approach). But I have no idea =20 > what such an intermediate language would look like. Though difficult, this is probably a more practical approach. =20 Statically extracting useful parallel programs is a very difficult =20 task. (Witness the emergence of OpenMP.) It is probably easier for =20 functional programs, but still. In related news, Areospace legal recently cleared the CellSPU backend =20= for upstream contribution to LLVM (http://llvm.org/) and its author is =20= finally committing it today. As has been mentioned, it's possible to =20 efficiently build LLVM IR in memory with Ocaml. Anyone interested in =20 leveraging SPUs from Ocaml in this manner could spool up quickly with =20= LLVM. Since LLVM has solid support for mainstream CPUs, so it would be =20= quite possible to write programs which were also portable to standard =20= SMP hardware. =97 Gordon