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=none 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 8C31DBC69 for ; Tue, 4 Dec 2007 18:33:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJMeVUfU4367nmdsb2JhbACBW41zAQEBBwQGKQ X-IronPort-AV: E=Sophos;i="4.23,249,1194217200"; d="scan'208";a="6471726" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail3-smtp-sop.national.inria.fr with ESMTP; 04 Dec 2007 18:33:34 +0100 Received: from gate.lan.gerd-stolpmann.de (dslb-088-068-209-103.pools.arcor-ip.net [88.68.209.103]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1IzbeC2oEP-0007Ux; Tue, 04 Dec 2007 18:33:28 +0100 Received: from flakew.lan.gerd-stolpmann.de (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 35EF5C0C6; Tue, 4 Dec 2007 18:33:25 +0100 (CET) Subject: Re: [Caml-list] minithread (was OCaml on Sony PS3) From: Gerd Stolpmann To: Christophe Raffalli Cc: caml-list@yquem.inria.fr In-Reply-To: <4754643A.6020503@univ-savoie.fr> 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> Content-Type: text/plain Date: Tue, 04 Dec 2007 18:33:24 +0100 Message-Id: <1196789604.25440.176.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+3CqT61C9C/TwYbLqikzaLaa6xUV2s8qvVyQx S+wKZYh51h/oa0hMgsEYnMZ2o/A0ZeFskZmXraG+4A5MIEPP/6 rqtOKq2rEEl7JeGHThILfqbT9zscwCH X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 christophe:01 raffalli:01 ocaml:01 runtime:01 runtime:01 lexing:01 stdlib:01 arrays:01 gerd:01 caching:01 mutation:01 model:01 Am Montag, den 03.12.2007, 21:16 +0100 schrieb Christophe Raffalli: > 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: What could work is that you really switch to a copying collector. That means that there are two minor heaps of fixed size, and a minor GC copies one heap to the other. While one heap is used, the other is unused. Every coprocessor would have such a pair of heaps. Of course, this means that: - You have very limited memory, and you have to set its max size in advance. This heap cannot be extended as needed. But this is ok for a coprocessor. - You waste half of the memory. E.g. if you want to have 64 K of heap, you have to buy 128 K. On the other hand, this saves a lot of code in the OCaml runtime, surely more than 64 K, so this is a net win. - Maybe even this works: The minor GC is done by the main processor, and the other heap is also there. This could work if the GC is not invoked too often. Such a copy collector is very small (the minor_gc.c file in the runtime has less than 300 lines, so you could have a miniature memory manager in only a few K). If you remove most features of the OCaml runtime, there are some chances that it really fits into the remaining memory: no I/O, no generic comparison, no backtraces, no MD5, no lexing, ... You couldn't use these features in the SPU anyway. From the stdlib I would only keep arrays and strings (no lists), and add a communication channel with the main processor. Of course, programming in this context then does not make any fun. I mean you'll get stack overflows really quickly. Maybe you can run very simplistic algorithms. On the one hand I really have doubts whether it makes sense to run OCaml in such an environment, but on the other hand it's fun to have such a thing at all... Gerd > > 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 > > _______________________________________________ > 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 -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------