Re: [Caml-list] minithread (was OCaml on Sony PS3)

[Mike Hogan <MikeHogan62@gmail.com>]

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.