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 SAA10192; Wed, 19 Feb 2003 18:15:22 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA09855 for ; Wed, 19 Feb 2003 18:15:21 +0100 (MET) Received: from epexch01.qlogic.org ([63.170.40.3]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h1JHFJP24300; Wed, 19 Feb 2003 18:15:20 +0100 (MET) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Feb 2003 11:14:03 -0600 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Feb 2003 11:14:03 -0600 Date: Wed, 19 Feb 2003 11:25:11 -0600 (CST) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: cc: James Leifer , Subject: Re: [Caml-list] Re: feature priorities (multithreading) In-Reply-To: <87fzqk5icy.fsf@uga.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Feb 2003 17:14:03.0047 (UTC) FILETIME=[4CF2AB70:01C2D83A] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 19 Feb 2003 cashin@cs.uga.edu wrote: > James Leifer writes: > > ... > > What kind of multithreading features do you need? It would be > > interesting to understand what would be useful in Ocaml, especially > > from people who have worked with Erlang, for example. > > Personally, I try to avoid threads because they usually make my > programs less portable and sometimes more complex. But many people > who do parallelizable computation, like scientific computations > involving matrices, like to increase performance by taking advantage > of SMP architectures. > > If the threads in a program only run on one processor, then all you > have is the overhead. If they run on different processors at the same > time, with access to the same main memory but with independent caches, > then the performance benefits start to compensate for the extra > complexity of multithreading. > With the increasing popularity of SMT CPUs (for example, the P4, and comming soon the Power5), multithreading for performance will become more usefull. For multithreading for performance, I like the cilk interface myself: http://supertech.lcs.mit.edu/cilk/ I still haven't wrapped my brain around JoCaml yet, so I can't say which is better. What I like about Cilk is that it allows you to effectively use a single CPU, or hundreds, with the same executable. There is a second use for multithreading: responsiveness. In a GUI program, you have multiple threads going at once. One is responding to GUI events, the others are performing various time consuming tasks. The alternative is to be continually polling the GUI- and if you forget to do that, you annoy your users. An example of this would be browsers- one (or more) threads are downloading files from the web server, while another thread is waiting on the GUI. So when you hit 'stop', the GUI can wake up and actually stop downloading the pages. Note that cilk style multithreading would *not* be usefull for solving this problem- cilk is purely a speed improvement. This is more why Java added multithreading. Note that cilk-style multithreading only makes sense with SMP, or at least SMT, environments and kernel-level threads. Java-style multithreading works just fine with userspace threads. Multithreading is more difficult to program than single threading, there is no doubt about that. Although, interestingly enough, I think purely functional programs would be easier to multithread than imperitive programs. The big bugbear of multithreaded programs- race conditions- are a side effect of, well, side effects. I've toyed occassional with the idea of having the compiler or run time environment add synchronization automatically. If possible, this would be the holy grail of multithreaded programming. The idea would be that objects only visible to one thread don't need any sort of synchronization. It's objects visible from two or more threads that need synchronization. So a garbage collection like algorithm could detect those objects that need synchronization and add it. Static analysis might also be usefull- I don't know. 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