From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA07272 for caml-redistribution@pauillac.inria.fr; Fri, 10 Mar 2000 08:59:35 +0100 (MET) Resent-Message-Id: <200003100759.IAA07272@pauillac.inria.fr> Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA13619; Wed, 8 Mar 2000 21:02:31 +0100 (MET) Message-ID: <20000308210231.55581@pauillac.inria.fr> Date: Wed, 8 Mar 2000 21:02:31 +0100 From: Xavier Leroy To: Simon Peyton-Jones , caml-list@pauillac.inria.fr Cc: "Norman Ramsey (E-mail)" Subject: Re: Interpreter vs hardware threads References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Simon Peyton-Jones on Tue, Mar 07, 2000 at 12:30:29AM -0800 Resent-From: weis@pauillac.inria.fr Resent-Date: Fri, 10 Mar 2000 08:59:34 +0100 Resent-To: caml-redistribution@pauillac.inria.fr > | Very lightweight > | threads do exist, see e.g. the call/cc-based threads of SML/NJ, but > | entail significant performance penalties not only on I/O, but also on > | the actual running speed of the sequential code. > Is that really so, Xavier? What percentage performance penalty do > you think is involved? 1%? 10%? Factor of 2? For SML/NJ, I think their stackless execution model (all activation records beging heap-allocated) entail a significant speed penalty for sequential code -- at least 20%, I'd say. But it sure gives you blazingly fast thread creation. The Concurrent Haskell approach that you describe is somehow less lightweight than the SML/NJ approach. In particular, thread creation is going to be more expensive because of the cost of allocating and setting up a new stack. Also, the memory consumption of each thread is going to be higher. I guess the SML/NJ approach could accommodate one million threads, while Concurrent Haskell sounds more in the 100 000s. Still, I agree the solution you outline is pretty lightweight. The expression "lightweight threads" is getting too vague. I guess we need several degrees of lightweightness, from SML/NJ's "ultra-lightweight threads" to POSIX's "not so lightweight threads", with Haskell's "pretty lightweight" threads and Caml's "lightweight, but no more" threads... > For potentially-blocking I/O operations it is true that there is > some extra work to do, much like a context switch. The pointers need > to be saved in a safe place in case GC strikes, and a global lock should > be released so that a new heavyweight thread can take over the business > of running the lightweight threads if the I/O blocks. But none of > this seems really expensive in terms of % of computation time, does it? You have to add to this the overhead on the I/O operation itself. If your threads build upon heavyweight threads for I/O, that should be negligible. (Say, one or two extra kernel context switches.) But if you have to perform I/O polling via select() (like OCaml bytecode threads do for maximal portability), the overhead becomes significant. (select() is one of the most expensive Unix system calls, in particular because the kernel has to scan a huge set of file descriptors just to determine which ones to wait upon; it's so bad that Unix 98 introduced an alternate form, poll(), that does exactly the same thing but with a more compact description of the f.d. sets.) - Xavier Leroy