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 55916BC69 for ; Sat, 2 Jun 2007 05:27:08 +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 l523R5t1016356 for ; Sat, 2 Jun 2007 05:27:07 +0200 X-IronPort-AV: E=Sophos;i="4.16,374,1175437800"; d="scan'208";a="97862510" 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; 02 Jun 2007 12:57:03 +0930 Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics From: skaller To: Brian Hurt Cc: caml-list@yquem.inria.fr In-Reply-To: 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> Content-Type: text/plain Date: Sat, 02 Jun 2007 13:26:58 +1000 Message-Id: <1180754818.5289.29.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 4660E389.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 val:01 val:01 endmatch:01 elif:01 inlined:01 recursive:01 lambdas:01 2007,:98 On Fri, 2007-06-01 at 19:49 -0400, Brian Hurt wrote: > > 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! That's partly true. For Felix, some functions are 'generated by the system'. For example val x = if a then b else c endif; looks cute, but actually is just sugar for: val x = match a with | true => b | _ => c endmatch which in turn is just sugar for val arg = a; fun matches_1 () => a == true; fun matches_2 () => true; fun handler_1() { tmp = b; } fun handler_2() { tmp = c; } if matches_1 () then handler_1() elif matches_2 () then handler_2() else error "Match failure"; x = tmp; except the real code is even worse than that. Felix guarantees compiler generated functions are inlined: such functions are always children and never recursive without going through a user function .. however they might exceed the inlining threshold .. they're inlined anyhow. This is because such 'automagically' generated functions can't be tagged 'inline' or 'noinline' by the end user. The reason the guarantee is made is simple: it's the only way to be sure the compiler reduces 'dumb C looking code' into 'dumb C code', that is, to ensure WYSIWIG. For example the above code 'had better' result in code like: if(!a) goto l1; x = b; goto l2; l1: x = c; l2: or Felix won't be as fast as C. The guarantee makes it possible to simplify the front end, by reducing 'everything' to lambdas, applications, and other fairly simply terms. -- John Skaller Felix, successor to C++: http://felix.sf.net