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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 7F225BC6D for ; Fri, 1 Jun 2007 18:52:03 +0200 (CEST) Received: from pih-relay06.plus.net (pih-relay06.plus.net [212.159.14.133]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l51Gq2kn003135 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jun 2007 18:52:03 +0200 Received: from [80.229.56.224] (helo=beast.local) by pih-relay06.plus.net with esmtp (Exim) id 1HuAM4-00014h-IH for caml-list@yquem.inria.fr; Fri, 01 Jun 2007 17:52:02 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics Date: Fri, 1 Jun 2007 17:46:34 +0100 User-Agent: KMail/1.9.7 References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <3d13dcfc0706010449k53f1c364gfd4db47c7c258725@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706011746.34724.jon@ffconsultancy.com> X-Miltered: at discorde with ID 46604EB2.004 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 markus:01 mottl:01 hash:01 ocaml:01 higher-level:01 inlining:01 compiler:01 compiler:01 inlining:01 frog:98 wrote:01 imho:01 partial:01 partial:01 You guys seem to have left me in the dust in this discussion. :-) On Friday 01 June 2007 17:14:36 Markus Mottl wrote: > Absolutely! E.g. we had to specialize hash tables for integer and > string keys I wholeheartedly agree with this. OCaml is lightning fast for 1=2 but dreadfully slow for (1,2)=(2,3). I'm sure this can be addressed easily enough. > I'd surely be happy to see the addition of some (optional) > higher-level code transformations to OCaml. Not just inlining, maybe > some partial evaluation of the resulting code, which could also reduce > code size if the compiler can prove that certain branches will not be > taken. General partial evaluation/specialization is another area that is too unpredictable to leave it entirely up to the compiler, IMHO. Like inlining, simple changes to existing programs have shown that "obvious" optimizations can slow things down a lot. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e