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 KAA11823; Sun, 11 Apr 2004 10:42:16 +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 KAA11783 for ; Sun, 11 Apr 2004 10:42:15 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3B8gCYM003936 for ; Sun, 11 Apr 2004 10:42:14 +0200 Received: from [192.168.1.200] (ppp116-94.lns1.syd2.internode.on.net [150.101.116.94]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i3B8frvM014317; Sun, 11 Apr 2004 18:11:54 +0930 (CST) Subject: Re: [Caml-list] exene and ocaml ? From: skaller Reply-To: skaller@users.sourceforge.net To: briand@aracnet.com Cc: skaller@users.sourceforge.net, Ville-Pertti Keinonen , caml-list@pauillac.inria.fr In-Reply-To: <16504.59825.814348.947278@soggy.deldotd.com> References: <16491.38344.186267.44292@soggy.deldotd.com> <1080807590.13854.260.camel@pelican> <6C27A642-83BE-11D8-96B0-000393863F70@exomi.com> <1080828521.13854.358.camel@pelican> <16504.59825.814348.947278@soggy.deldotd.com> Content-Type: text/plain Message-Id: <1081672912.20677.340.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 11 Apr 2004 18:41:53 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 threads:01 posix:01 threads:01 posix:01 optimised:01 gui:01 widget:01 threading:01 model:01 9660:01 glebe:01 kernel:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Keywords: X-UID: 243 On Sun, 2004-04-11 at 16:46, briand@aracnet.com wrote: > I was thinking about that statement... Is that really true ? If I > only have maybe something like 5-10 threads running, why would it be > such a problem ? Probably it wouldn't, but not the reference is to: >> I wouldn't use or recommend a massively multithreaded approach > I know almost nothing about the efficiency of posix threads. The problem isn't "posix threads" per se, but Unix. It isn't possible to use Unix kernel scheduling for efficient task switching. Even highly optimised systems like Solaris are required to cope with complex conditions which make it expensive to schedule a time slice. Also, small address space processors cannot cope with the linear addressing problem: unlike processes, threads share address space. If you have a lot of threads you need a lot of stacks, and they all have to grow 'arbitrarily' large, but there isn't enough address space for that .. even on a 64 bit machine the position is not good. So actually -- FAR from the garbage collector being a problem, the situation is exactly the opposite. It is the heavy memory demands of the linear stack which creates a problem a GC would have no problem dealing with. Felix solves some of these problems by cooperatively multi-tasking procedural continuations allocated on a GC managed heap and allows O(1) event driven scheduling. The architecture should support a GUI with one thread for every window (and I mean X level window not widget), a game with 10,000 sprites, a telco system managing 100K concurrent phone calls, or any other problem where you can factor your need for threads of control into (1) A few concurrent Unix style threads (2) A huge number of threads doing almost no work which can be scheduled on an event basis. A typical architecture would divide the Unix threads into a worker for each CPU which drives the cooperative threading on that CPU, and some I/O threads to gather and dispatch events between the worker event queues and the hardware. This model isn't useful for all problems. [eg -- it doesn't seem to fit parallel numerical computing needs] It also needs augmentation to include persistence/network transparency to support mobile agents, for example. Felix generates C++, but an Ocaml back end would be quite interesting .. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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