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=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id BF6EBBC69 for ; Tue, 4 Dec 2007 19:00:10 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPcjVUfYi+yen2dsb2JhbACPTgEBAQcEBgkg X-IronPort-AV: E=Sophos;i="4.23,249,1194217200"; d="scan'208";a="19977484" Received: from kuber.nabble.com ([216.139.236.158]) by mail4-smtp-sop.national.inria.fr with ESMTP; 04 Dec 2007 19:00:09 +0100 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Izc3z-0003Dg-Uf for caml-list@yquem.inria.fr; Tue, 04 Dec 2007 10:00:07 -0800 Message-ID: <14156018.post@talk.nabble.com> Date: Tue, 4 Dec 2007 10:00:07 -0800 (PST) From: Mike Hogan To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] minithread (was OCaml on Sony PS3) In-Reply-To: <4754643A.6020503@univ-savoie.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: MikeHogan62@gmail.com 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> <14116972.post@talk.nabble.com> <200712021419.01821.konrad@tylerc.org> <14121946.post@talk.nabble.com> <4754643A.6020503@univ-savoie.fr> X-Spam: no; 0.00; ocaml:01 model:01 coq:01 coq:01 entail:01 functors:01 functor:01 christophe:01 ocaml:01 powerpc:01 caching:01 mutation:01 model:01 cheers:01 christophe:01 Neat stuff. For anyone genuinely interested in this problem, a look at CorePy may be in order -- it is about the simplest model imaginable for processor-specific access and the Cell interface offers insight into the architectural specifics that would need to be addressed for the Cell. Not knowing Caml at all, really, I wonder if a similar approach can be applied to Caml -- basically "escape" to specialized SPU code wrapped in an encapsulation (a la mini-thread"?). If the SPU code can be autogenerated and transparently integrated using a Caml-based DSL of some sort, then that would be even better. I was also wondering recently if there is any practical possibility of code extraction from Coq to Python in order to make a verified CorePy application (basically CorePy as an IL) -- or is this just swapping one very difficult problem for another? Coq (which also seems to run fine on the PS3) seems to open up some interesting possibilities, for example optimization proofs where some algorithm "X" converted to a high-performance Cell-specific equivalent using some magic transformation "Y" results in the algorithm "Cell-X" whose results are equivalent to the original "X". Furthermore, the characteristics of the "Y"s developed along the way would seem to provide formal insight into what a "CoreCaml" language might entail. As an aside, would the Y's be a functors, "Cell" be a domain and the inverse of any A from "Cell" be the domain "algorithms that can be transformed to "Cell" equivalents using functor "A"" (and apologies in advance of this is a stupid question beneath an answer). Christophe Raffalli-2 wrote: > > > I propose the following idea for OCaml on Cell PowerPC or multicore > machine (this is just an idea, > there ay be a lot of thing I did not see ... in other word there is > probably a lot of work to do, but may be not too much): > > - Create two functions and one data type to start "mini-thread": > > type 'a result_channel > launch : int -> ('a -> 'b) -> 'a -> 'b result_channel. > get_result : 'b result_channel list -> 'b option > (or many similar functions to wait with or without blocking the result > for one or more mini-thread). > > Now the point is this: each mini-thread has its own minor-heap whose > size is given as the first argument with the following restrictions: > > 1) the minor heap is used as a cache : access to the major heap copy > the data in the minor heap. One need to mix the copying > minor GC with standard caching algorithm. > > 2) to ease the task 1), mutation of data in the heaps of the main thread > by a mini-thread is illegal (raises an exception in the main thread ? > Static check ?). This includes the arguments of the mini-thread. > > 3) a mini-thread can not start another mini-thread (raises an exception > in the main thread ? Static check) > > 4) 2-3) imply that a mini-thread can not access data of other > mini-threads and that the only way for the main thread to > get values from a mini-thread is via their 'b result_channel. Thus, if > you have a main thread M and many mini-threads T1 ... TN > runnnig, Ti can only acces its own data and the data of M (read only). > And, M can not acces the data of T1 ... TN. > > If you launch one minithread per SPU or CORE with a minor heap of the > correct size and you fine tune you application to produce not too much > cache misses, then, I think this simple model could be usefull ???? > > Cheers, > Christophe > > -- > Christophe Raffalli > Universite de Savoie > Batiment Le Chablais, bureau 21 > 73376 Le Bourget-du-Lac Cedex > > tel: (33) 4 79 75 81 03 > fax: (33) 4 79 75 87 42 > mail: Christophe.Raffalli@univ-savoie.fr > www: http://www.lama.univ-savoie.fr/~RAFFALLI > --------------------------------------------- > IMPORTANT: this mail is signed using PGP/MIME > At least Enigmail/Mozilla, mutt or evolution > can check this signature. The public key is > stored on www.keyserver.net > --------------------------------------------- > > > begin:vcard > fn:Christophe Raffalli > n:Raffalli;Christophe > org:LAMA (UMR 5127) > email;internet:christophe.raffalli@univ-savoie.fr > title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences > tel;work:+33 4 79 75 81 03 > note:http://www.lama.univ-savoie.fr/~raffalli > x-mozilla-html:TRUE > version:2.1 > end:vcard > > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- View this message in context: http://www.nabble.com/More-registers-in-modern-day-CPUs-tf4389938.html#a14156018 Sent from the Caml Discuss2 mailing list archive at Nabble.com.