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 KAA20020; Tue, 26 Nov 2002 10:02:58 +0100 (MET) 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 KAA20098 for ; Tue, 26 Nov 2002 10:02:57 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gAQ92tX20774; Tue, 26 Nov 2002 10:02:55 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA19863; Tue, 26 Nov 2002 10:02:54 +0100 (MET) Date: Tue, 26 Nov 2002 10:02:54 +0100 From: Xavier Leroy To: Blair Zajac Cc: caml-list@inria.fr Subject: Re: [Caml-list] Why systhreads? Message-ID: <20021126100254.A19708@pauillac.inria.fr> References: <20021123090806.GA633@la.iki.fi> <20021125110133.A12077@pauillac.inria.fr> <3DE2736D.F4FCC064@orcaware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3DE2736D.F4FCC064@orcaware.com>; from blair@orcaware.com on Mon, Nov 25, 2002 at 11:01:01AM -0800 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Blair Zajac wrote: > To summarize, for (2) system threads are required and and you can't > prevent blocking with user level threads easily or at all. For (3), > making the Ocaml system support SMP is "Too complex; too hard to > debug" and SMP boxes aren't all that popular. > Aren't these contradictory statements? > > For Ocaml to support a Ocaml program to have one thread to block on a > system call and to allow other threads to continue, doesn't this support > SMP? Does Ocaml support this? No to the first question. Yes to the second. By "supporting SMP", I mean having several threads executing Caml code in parallel, thus using the Caml runtime system in a concurrent fashion. This is the hard part. In the current implementation of systhreads, the Caml executor and runtime system is one big critical section: at most one thread can execute Caml code at a given time, but arbitrarily many other threads can be blocked on I/O (and thus isn't calling the Caml runtime system). Each thread leaves the critical section before calling a potentially blocking I/O operation, and re-enters it when the I/O completes. > I need the functionality to have multiple threads where one thread can > block and not stop the others, either due to the OS or to the Ocaml > runtime system. You have that functionality. What you don't have is the ability to keep several processors busy running Caml code. (As Markus said, you can still have C code running concurrently with Caml code, provided that the C code doesn't call the Caml runtime system.) Chris Hecker wrote: > Xavier saying 1.5x is not worth it is really strange to me; most > performance sensitive programmers I know would kill their mother to get > 1.5x. I wonder what factor would be worth it for Xavier? Factors of 10 are always nice :-) Just kidding. What I meant is the following: assume making the Caml runtime system thread-safe entails a 25% slowdown on program execution. (This can easily happen if e.g. we have to lock a mutex at each heap allocation.) Further assume that by doing so, you get a 1.5 speedup from hyperthreading. In the end, your program will run 1.5 * 0.75 = 1.12 times faster than its equivalent running on the standard, single-processor Caml runtime. It's not worth the effort. - Xavier Leroy ------------------- 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