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=1.2 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 84635BC6B for ; Thu, 11 Oct 2007 11:56:26 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFuPDUfAI/YBnWdsb2JhbACBWoxwAQEBAQsPCA X-IronPort-AV: E=Sophos;i="4.21,258,1188770400"; d="scan'208";a="4348768" Received: from ns.inescn.pt (HELO animal.inescn.pt) ([192.35.246.1]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Oct 2007 11:56:25 +0200 Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.13.8/8.13.6/9) with ESMTP id l9B9tsFi014790; Thu, 11 Oct 2007 10:55:54 +0100 (WEST) X-Virus-Scanned: amavisd-new at inescporto.pt Received: from animal.inescn.pt ([127.0.0.1]) by localhost (animal.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p45LGX4yx9oo; Thu, 11 Oct 2007 10:55:26 +0100 (WEST) Received: from [194.117.30.94] (morfina.inescn.pt [194.117.30.94]) by animal.inescn.pt (8.13.8/8.13.8/26) with ESMTP id l9B9svHv014690; Thu, 11 Oct 2007 10:54:58 +0100 (WEST) Message-ID: <470DF2F1.4020204@inescporto.pt> Date: Thu, 11 Oct 2007 10:54:57 +0100 From: Hugo Ferreira User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: skaller Cc: caml-list@yquem.inria.fr, Raj Bandyopadhyay Subject: Re: [Caml-list] Functional design for a basic simulation pipe. 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> <1192090171.16809.82.camel@rosella.wigram> In-Reply-To: <1192090171.16809.82.camel@rosella.wigram> Content-Type: text/plain; charset=ISO-8859-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 combinators:01 bug:01 model:01 rewriting:01 hmmm:01 skaller wrote: > 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. > Understood. >> 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. > Actually if I am not mistaken the example I refer to was using pthreads. When I read your code I assumed they were the equivalent of pthreads or some lighter version (user land, green threads). I guess this is not so. As for combinators I had initially thought there would be some kind of "functional magic" that could solve my problem without resorting to heavier duty stuff such as process or threads (at least for now because I am only testing ideas). > 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. > Again I figured someone would already have such an example using CPS so that I could use that without the trouble of learning the "low level" stuff that "requires some care to ensure it will work properly". > 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] > Hmmm... this is way over my head. I will stick to Ocaml and the simpler coding. Appreciate your feedback and explanation. Thanks.