From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 041B3BBAF for ; Thu, 15 Jul 2010 20:24:30 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoCAJfvPkzRVlk9kWdsb2JhbACBQ54pFQEBAQEJCwoHEQMfv0ECgnWCLQSDfg X-IronPort-AV: E=Sophos;i="4.55,209,1278280800"; d="scan'208,217";a="66506433" Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by mail4-smtp-sop.national.inria.fr with ESMTP; 15 Jul 2010 20:24:05 +0200 Received: from [69.254.201.214] (helo=[10.0.1.6]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OZT6K-0005rU-7q for caml-list@yquem.inria.fr; Thu, 15 Jul 2010 14:24:04 -0400 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: References: Content-Type: multipart/alternative; boundary=Apple-Mail-7-263333545 Message-Id: <95DEE0F8-E751-4712-8C33-B7F74DA361C9@refined-audiometrics.com> From: David McClain Subject: Re: [Caml-list] CML Discussion (was: Smart ways to implement worker threads) Date: Thu, 15 Jul 2010 11:24:04 -0700 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.753.1) X-ELNK-Trace: 7a0ab3eafc8cf994b22988ad1c62733440683398e744b8a4b542536cab43644e457f1d3695d381e9a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.254.201.214 X-Spam: no; 0.00; ocaml:01 implements:01 run-time:01 ocaml's:01 runtime:01 erlang:01 ocaml:01 reppy:01 implements:01 run-time:01 ocaml's:01 runtime:01 erlang:01 reppy:01 threads:01 --Apple-Mail-7-263333545 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, > So which 10% of the Event module is poorly implemented? Or is it > that the Event module doesn't have a spawn function and relies on > the Thread module? Is it fixable (could a CML module be created for > OCaml that faithfully implements the run-time described in Reppy's > book)? > That 10% was a figure of speech. I cant know how much the missing functionality affects the final application. Continuations are just another way of stating "spaghetti stacks", since they represent the entire "future" of the program -- i.e., the stacked contexts to be returned to later. My point was that OCaml's runtime is modeled against the use of a single machine stack - hence the great speed. Spaghetti stacks require explicit handling in the heap memory, and so would be slower. But the great thing about spaghetti stacks is that a "continuation" can be created as a first-class object, and easily reclaimed by the GC. [Examples: CML, Smalltalk, Erlang, others?] Technically, you can do anything in any language... so OCaml is technically "fixable" in this regard. But is it practical? feasible? I doubt it. Whether the shortcomings are important to you depends on your expectations and performance requirements. I have successfully used the notion of Reppy Channels in OCaml, Lisp, Scheme, and elsewhere. Only you can decide if the overhead of thread creation, the lack of GC thread reclamation, and the act of throwing new threads at every decision point, is too much, or inconsequential. Dr. David McClain Chief Technical Officer Refined Audiometrics Laboratory 4391 N. Camino Ferreo Tucson, AZ 85750 email: dbm@refined-audiometrics.com phone: 1.520.390.3995 web: http://refined-audiometrics.com --Apple-Mail-7-263333545 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Hi,


So which = 10% of the Event module is poorly implemented? Or is it that the Event = module doesn't have a spawn function and relies on the Thread module? Is = it fixable (could a CML module be created for OCaml that faithfully = implements the run-time described in Reppy's = book)?

That 10% was a figure of = speech. I cant know how much the missing functionality affects the final = application. Continuations are just another way of stating "spaghetti = stacks", since they represent the entire "future" of the program -- = i.e., the stacked contexts to be returned to = later.

My point was that OCaml's runtime is = modeled against the use of a single machine stack - hence the great = speed. Spaghetti stacks require explicit handling in the heap memory, = and so would be slower. But the great thing about spaghetti stacks is = that a "continuation" can be created as a first-class object, and easily = reclaimed by the GC. [Examples: CML, Smalltalk, Erlang, = others?]

Technically, you can do anything in = any language... so OCaml is technically "fixable" in this regard. But is = it practical? feasible? I doubt = it. 

Whether the shortcomings are = important to you depends on your expectations and performance = requirements. I have successfully used the notion of Reppy Channels in = OCaml, Lisp, Scheme, and elsewhere. Only you can decide if the overhead = of thread creation, the lack of GC thread reclamation, and the act of = throwing new threads at every decision point, is too much, or = inconsequential.

Dr. David McClain
Chief = Technical Officer
Refined Audiometrics = Laboratory
4391 N. Camino Ferreo
Tucson, AZ  85750

<= /html>= --Apple-Mail-7-263333545--