From: Brian Hurt <brian.hurt@qlogic.com>
To: Ocaml Mailing List <caml-list@inria.fr>
Subject: [Caml-list] Another newbie question (FAQ?): Cilk-like threading?
Date: Fri, 27 Sep 2002 15:09:45 -0500 (CDT) [thread overview]
Message-ID: <Pine.LNX.4.33.0209271446140.2088-100000@eagle.ancor.com> (raw)
Sticking my head up yet again: are there any plans to add cilk style
threading to Ocaml?
See:
http://supertech.lcs.mit.edu/cilk/
For more info on Cilk. But the short introduction: Cilk introduces the
idea of what you might consider "super light weight" threads, which act in
many ways like functions. You do not call these functions, you spawn
them. Spawning one of these cilk functions costs about 10x the cost of a
normal function call.
In the uniprocessor case, the spawning works exactly like a normal
function call. The "parent" spawning thread (calling function) stops
execution and the "child" spawed thread (called function) starts
execution. When the child thread exits (returns), the parent thread
resumes execution. Only one "real" (Java- or Posix- thread) is actually
created. It's in the multiprocessor case that it's interesting. Here
you'd spawn multiple worker threads (one per CPU), and another worker
thread could come along and start executing the parent thread (calling
function) in parallel to the child thread (called function). This is what
the extra overhead of spawning vr.s calling is for.
How this works in practice is that the code spawns bazillions of these
cilk "threads". At process start up, the work is split up until every CPU
has work to do- then the extra threads just work like somewhat heavy
procedure calls. All the programmer has to do is make sure he spawns
enough processes. And it's safe to be aggressive with spawning, because
extra (unnecessary) spawns aren't that expensive. This allows the same
binary executable to efficiently take advantage of a single CPU or
hundreds to thousands of CPUs.
Note this isn't a do-all end-all of threading. For example, cilk threads
don't deal well when you have contention and need mutual exclusion (or
some other form IPC). It works best when each thread produces it's own
output without affecting the other threads. Having cilk functions sharing
global data or modifying data structures passed in as arguments can cause
problems.
Brian
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
reply other threads:[~2002-09-27 20:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=Pine.LNX.4.33.0209271446140.2088-100000@eagle.ancor.com \
--to=brian.hurt@qlogic.com \
--cc=caml-list@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