From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] minithread (was OCaml on Sony PS3)
Date: Tue, 04 Dec 2007 18:33:24 +0100 [thread overview]
Message-ID: <1196789604.25440.176.camel@localhost.localdomain> (raw)
In-Reply-To: <4754643A.6020503@univ-savoie.fr>
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
------------------------------------------------------------
next prev parent reply other threads:[~2007-12-04 17:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-06 6:20 More registers in modern day CPUs Tom
2007-09-06 7:17 ` [Caml-list] " skaller
2007-09-06 9:07 ` Richard Jones
2007-09-06 14:55 ` Chris King
2007-09-06 15:17 ` Brian Hurt
2007-09-06 15:54 ` Harrison, John R
2007-09-06 17:10 ` David MENTRE
2007-09-06 18:27 ` Harrison, John R
2007-09-06 18:28 ` Christophe Raffalli
2007-09-06 18:48 ` Brian Hurt
2007-09-06 18:48 ` Pal-Kristian Engstad
2007-11-20 15:32 ` [Caml-list] OCalm on Sony PS3 (was Re: More registers in modern day CPUs) Mike Hogan
2007-11-21 17:20 ` Richard Jones
2007-11-21 19:05 ` [Caml-list] OCaml " Mike Hogan
2007-11-23 6:44 ` Mike Hogan
2007-12-02 10:14 ` [Caml-list] OCalm " Xavier Leroy
2007-12-02 16:22 ` Mike Hogan
2007-12-02 22:19 ` Konrad Meyer
2007-12-03 0:09 ` [Caml-list] OCaml " Mike Hogan
2007-12-03 20:16 ` minithread (was OCaml on Sony PS3) Christophe Raffalli
2007-12-04 14:25 ` [Caml-list] " David MENTRE
2007-12-04 14:37 ` Basile STARYNKEVITCH
2007-12-04 16:25 ` Mattias Engdegård
2007-12-04 17:33 ` Gerd Stolpmann [this message]
2007-12-04 18:00 ` Mike Hogan
2007-12-04 2:29 ` [Caml-list] OCalm on Sony PS3 (was Re: More registers in modern day CPUs) Gordon Henriksen
2007-09-06 20:48 ` [Caml-list] More registers in modern day CPUs Richard Jones
[not found] ` <20070906204524.GB10798@furbychan.cocan.org>
2007-09-06 20:59 ` Chris King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1196789604.25440.176.camel@localhost.localdomain \
--to=info@gerd-stolpmann.de \
--cc=Christophe.Raffalli@univ-savoie.fr \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).