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.6 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 79082BB84 for ; Tue, 23 Dec 2008 10:56:21 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0BALxEUEnUnw6UlGdsb2JhbACCO5EzAQEBAQkLCAkRBKpmWJEDhkM X-IronPort-AV: E=Sophos;i="4.36,270,1228086000"; d="scan'208";a="18822213" Received: from fhw-relay07.plus.net ([212.159.14.148]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 23 Dec 2008 10:56:21 +0100 Received: from [87.114.38.62] (helo=leper.local) by fhw-relay07.plus.net with esmtp (Exim) id 1LF3zw-0005M3-BZ for caml-list@yquem.inria.fr; Tue, 23 Dec 2008 09:56:20 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] More Caml Date: Tue, 23 Dec 2008 09:59:24 +0000 User-Agent: KMail/1.9.9 References: <157727.93194.qm@web111508.mail.gq1.yahoo.com> <20081222214456.GA8148@annexia.org> <200812230607.37399.jon@ffconsultancy.com> In-Reply-To: <200812230607.37399.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812230959.24662.jon@ffconsultancy.com> X-Plusnet-Relay: 806a0c7f8aa276501836b2a3b3dfebdd X-Spam: no; 0.00; ocaml:01 afaict:01 ocaml:01 ocaml's:01 arrays:01 allocations:01 deterring:98 frog:98 sml:01 wrote:01 stack:01 symbolic:01 symbolic:01 caml-list:01 arithmetic:01 On Tuesday 23 December 2008 06:07:37 Jon Harrop wrote: > Yes. I'll do a bit more work on it and then tidy it up and document it > before uploading it, unless there is any great interest from people now. Incidentally, I would like to know what performance issues (good and bad) people have with the current OCaml implementation? AFAICT, OCaml evolved from a family of languages that were only optimized for symbolic processing. Some of OCaml's relatives, like PolyML, were able to provide even faster symbolic processing than naive C but their numerical performance is 100x worse. These heavily-skewed performance characteristics rendered many ML implementations domain specific. I believe OCaml was the first ML to put an unusual amount of effort into optimizing other aspects, most notably high performance floating-point arithmetic and float arrays (where OCaml still thrashes SML/NJ and MLton). Moreover, I think OCaml became the world's favourite ML precisely because of this diversity. I am just looking at the simplest possible GC implementations, like shadow stack, and trying to envisage an ML implementation that puts a lot more effort into numerics and string processing and a lot less effort into symbolics. I am guessing the performance of allocation will be degraded 10-100x but many allocations can be removed. This leaves me wondering how much slowdown is acceptable without deterring a lot of users? Anyway, I'll try to implement a simple GC and get some concrete performance results first... -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e