From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 40B5ABC6B for ; Thu, 11 Oct 2007 10:09:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL52DUfLENaMn2dsb2JhbACOSgEBAQEHBAYJCBg X-IronPort-AV: E=Sophos;i="4.21,258,1188770400"; d="scan'208";a="2855871" Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Oct 2007 10:09:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHF0DUd5LCRs/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.21,258,1188743400"; d="scan'208";a="208305288" Received: from ppp121-44-36-108.lns10.syd7.internode.on.net (HELO [192.168.1.201]) ([121.44.36.108]) by ipmail01.adl2.internode.on.net with ESMTP; 11 Oct 2007 17:39:32 +0930 Subject: Re: [Caml-list] Functional design for a basic simulation pipe. From: skaller To: Hugo Ferreira Cc: caml-list@yquem.inria.fr, Raj Bandyopadhyay In-Reply-To: <470DC95D.8020701@inescporto.pt> References: <470C8199.4080708@inescporto.pt> <1192005274.6285.4.camel@rosella.wigram> <470CA488.1070804@inescporto.pt> <1192028408.6198.31.camel@rosella.wigram> <1192031761.6728.31.camel@rosella.wigram> <470DC95D.8020701@inescporto.pt> Content-Type: text/plain Date: Thu, 11 Oct 2007 18:09:31 +1000 Message-Id: <1192090171.16809.82.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; 0100,:01 0100,:01 hacked:01 model:01 ocaml:01 ocaml:01 combinator:01 combinators:01 combinator:01 parallelism:01 bug:01 model:01 rewriting:01 slave:98 paging:98 On Thu, 2007-10-11 at 07:57 +0100, Hugo Ferreira wrote: > Hello, > > skaller wrote: > > On Thu, 2007-10-11 at 01:00 +1000, skaller wrote: > >> On Wed, 2007-10-10 at 11:08 +0100, Hugo Ferreira wrote: > >>> Hello, > >>> Apologies for being so obtuse but I cannot to see how this solves my > >>> problem. > >>> let exp = a |> b |> c > > > >> A function is a slave, it is *called* with its argument. > >> you cant *read* the arguments. > > > > BTW: what you want is something like this 'concept demo' > > I hacked up in Felix (notes below). > > > > a -> b -> c -> d ->+ > > ^ | > > | | > > +--------<---------+ > > > > Basically yes. Closer to this though: > > a -> b -> c -> d ->+-> e -> f > ^ | > | | > +--------<---------+ > I know the design I showed didn't match your specifications: it was only intended as a (working) demo of the idea of a 'chips and wires' model. > The solution below is basically the same suggestion I got (in Ocaml) > from someone else. I guess this is the way to go then. Unfortunately (at least without control inversion patch) it is not possible to do this in Ocaml without using pthreads. It is possible to *emulate* it, as I mentioned, using some combinator libraries, but to make this work you have to structure your code in a rather 'peculiar' way to allow the combinators to actually work: the combinator style approach has the disadvantage (in Ocaml without control inversion patch) of an un-natural programming form. The pthreads/Event module based approach is fully natural but doesn't scale because pthreads don't, and it is inefficient because it synchronises using primitives designed to support multi-processing when basic circuits do not need any parallelism. In addition, pthreads have a termination and deadlocking problem the cooperative system does not: it cannot deadlock, and there is no facility to explicitly terminate fibres -- they die when they become unreachable, so the programmer simply has to ensure there is no gratuitous visibility. Fibres CAN livelock/starve, and sometimes you find they die from deadlock unexpectedly due to a bug. The bottom line is that the chips and wires model has nice properties BUT it is quite low level and requires some care to ensure it will work properly. It is, however, the only option for simulations with a high object count. Pthreads fail on small numbers (a few K threads). Stack swapping solutions cannot work on 32 bit machines. On 64 bit machines they're more viable but either suffer a performance hit copying the stack or a memory usage hit using VM paging. [i.e. 4K on most systems, which could be way above the object size which might be only a few bytes in a cellular automata] Using the heap works best for large object counts, however it requires continuation passing support of some kind. I would have to mention Mlton in passing because it uses a rather clever system with VM based stack swapping, but the stacks are actually compacted like the heap: it is quite clever IMO. I think Mlton also offers more or less transparent interfaces so code can work with either fibres or pthreads in various mixes without rewriting the algorithms, which is quite cool. [But I'm no expert, perhaps Steven Weeks will comment more authoritatively] -- John Skaller Felix, successor to C++: http://felix.sf.net