From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA22769; Fri, 27 Sep 2002 22:04:53 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA22878 for ; Fri, 27 Sep 2002 22:04:52 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from epexch01.qlogic.org ([63.170.40.3]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g8RK4p505527 for ; Fri, 27 Sep 2002 22:04:51 +0200 (MET DST) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Fri, 27 Sep 2002 15:04:50 -0500 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Fri, 27 Sep 2002 15:04:50 -0500 Date: Fri, 27 Sep 2002 15:09:45 -0500 (CDT) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Ocaml Mailing List Subject: [Caml-list] Another newbie question (FAQ?): Cilk-like threading? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 27 Sep 2002 20:04:50.0909 (UTC) FILETIME=[234090D0:01C26661] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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