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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr 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 B4021BC99 for ; Fri, 1 Jun 2007 07:45:25 +0200 (CEST) Received: from pih-relay06.plus.net (pih-relay06.plus.net [212.159.14.133]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l515jPOO007211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jun 2007 07:45:25 +0200 Received: from [80.229.56.224] (helo=beast.local) by pih-relay06.plus.net with esmtp (Exim) id 1Htzwy-0002io-D8; Fri, 01 Jun 2007 06:45:24 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: Alain Frisch Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics Date: Fri, 1 Jun 2007 06:39:52 +0100 User-Agent: KMail/1.9.7 References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <1180660974.15528.126.camel@rosella.wigram> <465FAF0B.5060700@inria.fr> In-Reply-To: <465FAF0B.5060700@inria.fr> Cc: caml-list@yquem.inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706010639.53307.jon@ffconsultancy.com> X-Miltered: at concorde with ID 465FB275.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 inlining:01 ocaml:01 compiler:01 inlining:01 compiler:01 iter:01 higher-order:01 arrays:01 frog:98 polymorphic:01 wrote:01 rewrite:01 caml-list:01 inline:01 On Friday 01 June 2007 06:30:51 you wrote: > Having said that, I don't see how opposing a more effective inlining and > specialization strategy would let the programmers write better code. My impression is that this is unsolved in the context of OCaml. The compiler lets you fiddle with the inlining threshold but the results are unpredictable: inlining often worsens performance in symbolic 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 :-/ I see no better alternative. In this case, I don't even think a well-written version would be significantly longer. Look at my ray tracer, the fast OCaml is as ugly as the fast C++ even though the C++ compiler does many of the optimizations that people have cited. > 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. I think you should do whatever is clearest if you ask yourself such questions. Only rewrite in a more efficient form if the profiler tells you that you must. I agree that more optimization by the OCaml compiler might be nice (e.g. specializing higher-order functions over float arrays) but I do not believe it would have helped in this case. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e