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 3F38CBC6B for ; Fri, 1 Jun 2007 03:23:04 +0200 (CEST) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l511N1MU001881 for ; Fri, 1 Jun 2007 03:23:03 +0200 X-IronPort-AV: E=Sophos;i="4.16,371,1175437800"; d="scan'208";a="97424762" Received: from ppp9-14.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.9.14]) by ipmail03.adl2.internode.on.net with ESMTP; 01 Jun 2007 10:52:57 +0930 Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics From: skaller To: Alain Frisch Cc: Jon Harrop , caml-list@yquem.inria.fr In-Reply-To: <465F3E8C.10404@inria.fr> References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <200705311008.16662.jon@ffconsultancy.com> <5195a210705310222p6aa8482fr70e7bf2b2b631b72@mail.gmail.com> <200705311127.28639.jon@ffconsultancy.com> <465F3E8C.10404@inria.fr> Content-Type: text/plain Date: Fri, 01 Jun 2007 11:22:54 +1000 Message-Id: <1180660974.15528.126.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 465F74F5.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 0200,:01 frisch:01 ocaml:01 inlining:01 inlining:01 stl:01 'list:01 syntax:01 syntax:01 internals:01 compiler:01 parser:01 optimise:01 optimise:01 On Thu, 2007-05-31 at 23:30 +0200, Alain Frisch wrote: > Jon Harrop wrote: > >> My point, however, is that MLton and OCaml are being fed the same > >> code, and if OCaml performs specializing and proper inlining, it will > >> get almost twice its current performance. > > > > The OCaml compilers are designed to handle good code. > > Could you elaborate? Do you mean that a code than would benefit from > inlining is not a good code? A general comment may explain this: some systems specifically provide performance which is readily computable. For example in the design of STL all the functions provided are fast with specified O() performance. Slower functions like 'List.nth' are not provided because the speed of a program is not evident in the syntax. 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. The idea is that this gives the programmer *control* over performance. It may require more work, but the lack of 'magic' which can defeat manual optimisation attempts is seen as a virtue. Basically the code is seen as that: an encoding of an algorithm. If you want it to run faster, change your encoding. The opposite approach -- to add as much smarts to the optimiser as possible -- can generate much better code in many circumstances, but it requires much more knowledge of complex internals by the programmer to change the generated encoding where the magic didn't work so well -- and in turn this puts pressure on the compiler vendor to improve the 'smartness' of their optimisation heuristics .. simply because on one else has the expertise to do so. Someone (as usual no URL sorry) wrote a paper roughly titled 'guaranteed optimisations' which is actually an interesting perspective on this whole scenario. The fact is, no programmer can possible handle the complex recoding an automatic algorithm can, so there is always going to be a tension between 'do it yourself' and 'automagical' optimisation strategies. Ocaml seems to pick a good mix. CF: dypgen GLR parser, old version: 95++% of all compile time. New version with recoding of data structures etc is down to about 20--% of compile time .. it's over an order of magnitude faster. IMHO: whilst quite a lot is known about how to optimise executable code .. almost nothing is understood about how to optimise data structures (automatically I mean). -- John Skaller Felix, successor to C++: http://felix.sf.net