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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id A01B4BC69 for ; Sun, 10 Jun 2007 14:58:36 +0200 (CEST) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5ACwYkG007750 for ; Sun, 10 Jun 2007 14:58:35 +0200 X-IronPort-AV: E=Sophos;i="4.16,405,1175437800"; d="scan'208";a="101336000" Received: from ppp2-129.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.2.129]) by ipmail03.adl2.internode.on.net with ESMTP; 10 Jun 2007 22:28:32 +0930 Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics From: skaller To: Jon Harrop Cc: caml-list@yquem.inria.fr In-Reply-To: <200706101310.52165.jon@ffconsultancy.com> References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <200706011813.48515.jon@ffconsultancy.com> <46641BC1.9090305@cs.umd.edu> <200706101310.52165.jon@ffconsultancy.com> Content-Type: text/plain Date: Sun, 10 Jun 2007 22:58:30 +1000 Message-Id: <1181480310.6187.23.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 466BF57A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 0100,:01 higher-order:01 val:01 rewriting:01 rewriting:01 variants:01 subtype:01 ocaml:01 unboxing:01 inlining:01 axioms:01 camlp:01 compiler:01 semantics:01 On Sun, 2007-06-10 at 13:10 +0100, Jon Harrop wrote: > More generally, applications such as term rewriters can benefit from > specialized higher-order functions that incorporate this physical equality > based optimization. My term rewriter used an "id_map" function: > > val id_map : ('a -> 'a) -> 'a array -> 'a array > > which returns the input when possible. This can avoid a lot of unnecessary > allocation during rewriting and doubled the performance of the whole program! Generally this often comes up rewriting terms: match x with | A a -> A (f a) | B b -> B b | ... This is slower than match x with | A a -> A a | B _ as p -> p | ... for the same reason: it avoids creating a new term equal to the old one by just using the old term. This is particularly useful with polymorphic variants: | #subtype as s -> s In general though, Ocaml won't attain the performance Felix or Mlton gain from whole program analysis, unboxing, and monomorphisation. It compensates by providing (usually) rapid compile and build times, a fast run time engine, and moderate optimisations. It's somehow a pity the project isn't a bit more open, because some of this stuff: more inlining, monomorphisation, additional analysis, semantic axioms, etc, could be written by interested parties. However the only hooks available at the moment are in the front end with camlp4. I might be interesting if the build system could "slot in" third party analysis phases in a standardised way. The idea here is that such modification would be strictly isolated, extending the compiler by: (a) an initialisation hook (b) a term -> term analysis (c) a command line switch to enable so that the result is more or less guaranteed to be the standard Ocaml unless you switch on the extra feature. When switched on, the analysis has an obligation to preserve semantics (i.e. only optimisations are permitted). With such a build system modification, more users could choose to 'plug in' such optimisations in testing builds of the compiler. Obviously, such optimisations have limited opportunities compared with arbitrary patches, but still, perhaps this could provide a way for the community to build and assess a limited but hopefully useful contribution. The INRIA team could also supply testing optimisations using the same mechanism. With the bytecode compiler, it may even be possible to direct loading of the optimisation phases dynamically with the command line switches. Well, I know nothing about the ocaml compiler at all, so I have no idea whatsoever if this suggestion has any merit. I do know, however, that at certain points in compilation of Felix codes, it would be possible to add in arbitrary optimisation passes which are close to if not totally purely functional (and thus easy to make optional). I believe Mlton also supports "optional optimisations" at various points in compilation. How possible is this for Ocaml? -- John Skaller Felix, successor to C++: http://felix.sf.net