From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 44A2EBC8B for ; Mon, 7 Feb 2005 18:30:57 +0100 (CET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j17HUtdJ019191 for ; Mon, 7 Feb 2005 18:30:56 +0100 Received: from [192.168.1.200] (ppp212-197.lns2.syd3.internode.on.net [203.122.212.197]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id j17HUUp9054965; Tue, 8 Feb 2005 04:00:31 +1030 (CST) Subject: Re: [Caml-list] The boon of static type checking From: skaller Reply-To: skaller@users.sourceforge.net To: Ville-Pertti Keinonen Cc: Brian Hurt , Jon , caml-list@yquem.inria.fr In-Reply-To: <1107773824.654.43.camel@localhost> References: <1107773824.654.43.camel@localhost> Content-Type: text/plain Organization: Message-Id: <1107797428.13571.151.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 08 Feb 2005 04:30:30 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4207A5CF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 wrote:01 gcc:01 inlining:01 ocaml:01 inlining:01 closures:01 closures:01 hof:01 curried:01 inlined:01 gotos:01 applicative:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Mon, 2005-02-07 at 21:57, Ville-Pertti Keinonen wrote: > On Sun, 2005-02-06 at 23:34 -0600, Brian Hurt wrote: > > > optimizations to it. Of course, the more I look at SSA, the more it looks > > like a functional language to me. So, in effect, the GCC optimization > > While the single-assignment aspect of SSA could be considered > "functional", representing control flow using blocks and branches can't. > > > Don't assume that inlining is optimization. Actually, it generally isn't. > > Note that for OCaml, more aggressive inlining could be a significant > improvement, not because it would eliminate calls, but because it could > eliminate closures. Well, Felix can eliminate direct calls, and without any complex flow control. This is done precisely to eliminate closures, since in Felix the overhead is quite large. In addition, the code is much smaller. For example, this code: for {i=0;} {i<10} {i++;} { for(j=0} ... for {k=0} consisting of 8 or so nested loops, where 'for' is actually a HOF, and curried functions are represented by a function which returns the closure of a nested function. This code takes a LONG time to run without optimisation -- it has to create 4 closures to do a loop .. and in the inner loop that's expensive! However since all the arguments are manifest, the whole thing can be inlined, resulting in a chain of conditional gotos with some increments which runs 100-1000 times faster and is 20 times smaller. > Obviously this doesn't apply to C++. Sure it does -- although C++ doesn't have proper function closures, it does have other related facilities -- applicative objects, and methods for example. What it does lack is lexical scoping, meaning you have to construct closures by hand (or use Felix which does it for you :). In some senses, in C++ inlinling is used to eliminate abstraction and turn typed code into untyped code (after type checking), where Ocaml would use a different technique. So perhaps inlining in Ocaml 'isn't usually an optimisation' but in C++ it is mandatory. Not inlining at all isn't even marginally acceptable: without it you'd have to use casts as in C, and forget OO style abstraction (eg get/set methods) because it would impact performance. In addition, note that function calls can cost a lot more than just a CALL machine instruction: don't forget functions have arguments ... and also use registers. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net