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 4D832BC69 for ; Sat, 2 Jun 2007 01:44:28 +0200 (CEST) Received: from bsd4.nyct.net (mail-out8.nyct.net [216.139.141.8]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l51NiQKq011301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Jun 2007 01:44:27 +0200 Received: from [192.168.42.2] ([216.139.135.144]) by bsd4.nyct.net (8.13.4/8.13.4) with ESMTP id l51NhlCQ090288; Fri, 1 Jun 2007 19:43:49 -0400 (EDT) (envelope-from bhurt@spnz.org) Date: Fri, 1 Jun 2007 19:49:00 -0400 (EDT) From: Brian Hurt X-X-Sender: bhurt@localhost To: skaller Cc: Brian Hurt , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics In-Reply-To: <1180740393.5142.26.camel@rosella.wigram> Message-ID: References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <891bd3390706010429g2ac722bfmc6932b15393a62b9@mail.gmail.com> <20070601214326.e0a939a6.mle+ocaml@mega-nerd.com> <200706011258.59177.jon@ffconsultancy.com> <604682010706010718x42221e8rde56317905f5c972@mail.gmail.com> <466033EC.3050909@janestcapital.com> <1180740393.5142.26.camel@rosella.wigram> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at discorde with ID 4660AF5A.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 inlining:01 compiler:01 compiler:01 inlined:01 inlining:01 coefficients:01 compilation:01 flags:01 2007,:98 compilers:01 wrote:01 wrote:01 caml-list:01 inline:01 On Sat, 2 Jun 2007, skaller wrote: > On Fri, 2007-06-01 at 10:57 -0400, Brian Hurt wrote: >> And the third case, where inlining opens up new >> possibilities for optimization- that almost has to be done by the >> compiler, as it depends upon what optimizations the compiler can, and >> will, apply to the newly inlined function. This is something I trust >> the compiler to do more than I trust even me to do correctly. > > It's NOT so easy to predict how much optimisation will result > from inlining. Just think about it, you have a tree of inlining > opportunities, if do you really want to attempt to estimate the > coefficients on N inlining choices just to decide if you'll > inline or not? Nor is it easy for the programmer to guess how much optimization will result from inlining! What with different compilers with different optimization strategies, complex interactions between compiler strategies, and even compiler strategies being enabled or disabled depending upon what compilation flags given. Plus you have the effect of changing codes bases- any decision as to wether to inline or not has to be revisited every time either code changes. Plus, the decision to inline is dependent upon code in probably widely disseperate locations. > > I doubt it. The compiler will make one guess whether to inline > or not based on a some fast heuristic, and then commit. Yep. And I'm saying that heuristic is likely to be more accurate than the programmers guess. Brian