From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA21287 for caml-redistribution@pauillac.inria.fr; Thu, 2 Mar 2000 19:31:26 +0100 (MET) Resent-Message-Id: <200003021831.TAA21287@pauillac.inria.fr> 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 TAA01335 for ; Thu, 2 Mar 2000 19:21:56 +0100 (MET) Received: from mail12.svr.pol.co.uk (mail12.svr.pol.co.uk [195.92.193.215]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA11967 for ; Thu, 2 Mar 2000 19:21:54 +0100 (MET) Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12QaEO-00019u-00 for caml-list@inria.fr; Thu, 02 Mar 2000 18:21:48 +0000 Received: from modem-43.arnor.dialup.pol.co.uk ([62.136.125.171] helo=toy.william.bogus) by mail17.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12QaEM-0004VY-00 for caml-list@inria.fr; Thu, 02 Mar 2000 18:21:47 +0000 Received: (from williamc@localhost) by toy.william.bogus (8.8.7/8.8.7) id SAA13646; Thu, 2 Mar 2000 18:18:32 GMT Date: Thu, 2 Mar 2000 18:18:32 GMT Message-Id: <200003021818.SAA13646@toy.william.bogus> From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: caml-list@inria.fr Subject: Re: Interpreter vs hardware threads Newsgroups: lists.caml In-Reply-To: <38bd773a@tequila.cs.yale.edu> References: <14518.34203.741447.637489@gargle.gargle.HOWL> <38BC93FC.65E3ED43@in.ot.com.au> <38bd773a@tequila.cs.yale.edu> X-Mailer: VM 6.34 under Emacs 20.2.1 Resent-From: weis@pauillac.inria.fr Resent-Date: Thu, 2 Mar 2000 19:31:26 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Stefan Monnier writes: > >>>>> "Max" == Max Skaller writes: > > Asume LOTS of threads (thousands). > > (insert-file "many-threads-bad-design") > > > [Hardware threads are not fast enough] > > [ I assume you mean OS threads, since hardware-supported threads > are not very common. ] > > I guess it depends on the OS and the pthreads implementation, but > it seems that they are usually pretty fast (i.e. fast enough that > people more or less stopped trying to make them faster). I think you are being patronising from a position of innocent ignorance. Judging by Max's .sig he's doing embedded telecoms boxes, something like a GSM HLR which juggles many thousands of concurrent transactions in some ghastly protocol or other. Typically the logic of each transaction is encoded in an unstructured FSM---the same way as the wretched committees "specify" them---rendered literally in C/C++. That's very fiddly and leads to bugs, hence loss of revenue on a telephone-number scale, and a well-founded reluctance to add features. The convenience of using threads and a more sensible language would pay for some loss of performance, but obviously a massive hit for using lots of threads is unacceptable. IIRC, Linux native pthreads, for one, aren't at the moment meant to be used in huge numbers---the flood-test performance of those Linux Java VMs which map Java threads onto them supposedly suffers compared with those that don't. But Xavier would be able to tell us more about that :). (Of course, one could always ask the ocaml team that won the ICFP competition in such spectacular fashion to knock off an ocaml-to-event-driven-FSM compiler ...) Max---if you end up using ocaml for embedded work I'd be very interested to hear about it.