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 29524BBAF for ; Thu, 15 Jul 2010 19:50:32 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgCAGLnPkzRVdW0kGdsb2JhbACDH5AMjDEIFQEBAQEJCQwHEQMfrgE7gg+GBy6IUwEBAwWELXIEg36EUg X-IronPort-AV: E=Sophos;i="4.55,209,1278280800"; d="scan'208,217";a="66505382" Received: from mail-yx0-f180.google.com ([209.85.213.180]) by mail4-smtp-sop.national.inria.fr with ESMTP; 15 Jul 2010 19:50:31 +0200 Received: by yxm8 with SMTP id 8so226102yxm.39 for ; Thu, 15 Jul 2010 10:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=nnCyisk3XZJBBYqtiDenXnZOCS2yU4RTUizdbeKOwGA=; b=Re3h5R53VXjhlUdhQJqQtHV4VEdGnjkYuK/5fgLWY66iSTIzZeg0L4jwTh1nQU6+bs gWcZ52mVIr7c2/WkQuJjjghI8oIlJiehKniZG+NNnvzlwJNZiZLE9a7OHSwGbQhiDYbs BW97v9vIsV9CdIyKrRZPMwSZku0j33PXM+/4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ANPvgIk02zspHUi9QVFRlWzzELta3FE1Q+cbbn+g1iFMIpK1eSqABzlN/NmlNiF9xE VS1lNCgPi5XIfMjV/ekKqcPPOl22iAt/xTKB0gAKIDINabA+22rIbsjrCeYRaI32r4b3 rWAkQ07kRPNl1XYVGQP5uVOE8XcwLuPwwvsAM= MIME-Version: 1.0 Received: by 10.101.176.35 with SMTP id d35mr20809981anp.107.1279216230695; Thu, 15 Jul 2010 10:50:30 -0700 (PDT) Received: by 10.100.212.6 with HTTP; Thu, 15 Jul 2010 10:50:30 -0700 (PDT) Date: Thu, 15 Jul 2010 12:50:30 -0500 Message-ID: Subject: CML Discussion (was: Smart ways to implement worker threads) From: Rich Neswold To: caml-list@yquem.inria.fr Cc: Romain Beauxis Content-Type: multipart/alternative; boundary=001636c5c1a70583dc048b70bdfb X-Spam: no; 0.00; ocaml's:01 ocaml:01 ocaml:01 implements:01 run-time:01 ocaml's:01 implements:01 run-time:01 blog:98 blog:98 threads:01 threads:01 wrote:01 wrote:01 implemented:02 X-Attachments: cset="UTF-8" cset="UTF-8" --001636c5c1a70583dc048b70bdfb Content-Type: text/plain; charset=UTF-8 On Thu, Jul 15, 2010 at 11:19 AM, David McClain < dbm@refined-audiometrics.com> wrote: > That is not the same as OCaml's architecture, and so OCaml can implement > about 90% of CML but that last 10% might kill your dreams. CML likes to > spawn potential handlers, of which only one will get the go ahead. The > others are expected to die, after possibly cleaning up state. > 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)? I thought I read some details, recently, which described CML threads implemented as continuations rather than system threads, which made them inexpensive (relative to OS threads) to create. I'll have to go through my blog lists to see where I read that. Thanks for your insights! -- Rich Google Reader: https://www.google.com/reader/shared/rich.neswold Jabber ID: rich@neswold.homeunix.net --001636c5c1a70583dc048b70bdfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 11:19 AM, David McClain=C2= =A0<db= m@refined-audiometrics.com>=C2=A0wrote:
That is not the same as OCaml&#= 39;s architecture, and so OCaml can implement about 90% of CML but that las= t 10% might kill your dreams. CML likes to spawn potential handlers, of whi= ch only one will get the go ahead. The others are expected to die, after po= ssibly cleaning up state.

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 modul= e be created for OCaml that faithfully implements the run-time described in= Reppy's book)?

I thought I read some details, recently, which describe= d CML threads implemented as continuations rather than system threads, whic= h made them inexpensive (relative to OS threads) to create. I'll have t= o go through my blog lists to see where I read that.

Thanks for your insights!
=
=C2=A0
--
Rich

Google Reader: https://www.google.com/reader/shared/= rich.neswold
Jabber ID: rich@neswold.homeun= ix.net
--001636c5c1a70583dc048b70bdfb-- 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--