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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 7C016BCAD for ; Fri, 1 Jun 2007 07:30:53 +0200 (CEST) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l515UrIt000772 for ; Fri, 1 Jun 2007 07:30:53 +0200 Received: from [192.168.0.1] (rke75-3-82-229-183-156.fbx.proxad.net [82.229.183.156]) by smtp3-g19.free.fr (Postfix) with ESMTP id 8E37D5A175; Fri, 1 Jun 2007 07:30:52 +0200 (CEST) Message-ID: <465FAF0B.5060700@inria.fr> Date: Fri, 01 Jun 2007 07:30:51 +0200 From: Alain Frisch User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: skaller Cc: Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <200705311008.16662.jon@ffconsultancy.com> <5195a210705310222p6aa8482fr70e7bf2b2b631b72@mail.gmail.com> <200705311127.28639.jon@ffconsultancy.com> <465F3E8C.10404@inria.fr> <1180660974.15528.126.camel@rosella.wigram> In-Reply-To: <1180660974.15528.126.camel@rosella.wigram> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 465FAF0D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; frisch:01 frisch:01 ocaml:01 ocaml:01 syntax:01 inlining:01 inlining:01 compiler:01 iter:01 abstraction:01 modular:01 compilers:01 polymorphic:01 wrote:01 compile:01 skaller wrote: > So what I believe Jon and Xavier mean here is that the > Ocaml compilers compile code down to stuff which is easily > predicted in terms of the input syntax. no magic like > invariant code motion: What You See is What You Get. I generally agree that automatic optimizations should not change too much the behavior of programs unless they are very easy to understand and predict; indeed we don't want to rely on subtle properties of the code and see the performances degrade unexpectedly when we change a tiny thing. Having said that, I don't see how opposing a more effective inlining and specialization strategy would let the programmers write better code. Quite the contrary (manual inlining? come on...) in my opinion. These optimizations are not so much about producing more efficient programs; there're about letting the programmer write cleaner code. So maybe the current Ocaml compiler expects good code as Jon says, but it forces us to write not-so-good one :-/ A functional programmer has reasons to become schizophrenic if he must ask himself questions such as "should I make this piece of code a function or write it inline?" or "should I restrict the type of this polymorphic function?" or "should I use Array.iter or write a for loop?" all the time. MLton's strength is that you don't have to pay the price for abstraction, i.e. cleaning up your program (by factorizing it or making it more modular) does not degrade performance. I have no experience with MLton, but I don't believe that performances are much more difficult to predict than with OCaml (Stephen?). Alain