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=1.0 required=5.0 tests=AWL,SPF_NEUTRAL 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 B1ECEBC6B for ; Fri, 1 Jun 2007 16:15:06 +0200 (CEST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l51EF4qO021056 for ; Fri, 1 Jun 2007 16:15:05 +0200 Received: by wa-out-1112.google.com with SMTP id m28so630842wag for ; Fri, 01 Jun 2007 07:15:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iiKr/g3Qa7RcD0/wJbbqPXc0EVpxzUkkkMfVzSTaJ00Vt2JNFK9ZKxY3jQIffUhqQOO7HhxfQ8rzMwcR5b4ihx4koEc5+oyL7aGGqTeD87qTyHSCIEU+EG6q2FBy3ROm4onsUx77VgqEraStvS3vd2fSUXhoA3r2g3X3uI9DZJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TIvha11/tfWeb6+T6QNJz+/kSktx/VGbNuBeXSnFS8CAWdnB7RR1faxgfDzyeBKXnJBjxg/zsxgDxhD4S6hhs2szyha1Sv+2qQjwCiKUoNMViy6Q7VabOR86XGjhJbufgKQuJWi4qRPMYqAEiKOuX2p0j05/GZnSge0SqzHB+xU= Received: by 10.114.199.1 with SMTP id w1mr1857104waf.1180707304175; Fri, 01 Jun 2007 07:15:04 -0700 (PDT) Received: by 10.114.130.2 with HTTP; Fri, 1 Jun 2007 07:15:04 -0700 (PDT) Message-ID: <604682010706010715t7d7e503bm82a817338685b9f8@mail.gmail.com> Date: Fri, 1 Jun 2007 10:15:04 -0400 From: "Stephen Weeks" Sender: stephentweeks@gmail.com To: "Alain Frisch" Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics Cc: skaller , caml-list@yquem.inria.fr In-Reply-To: <465FAF0B.5060700@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <200705311008.16662.jon@ffconsultancy.com> <5195a210705310222p6aa8482fr70e7bf2b2b631b72@mail.gmail.com> <200705311127.28639.jon@ffconsultancy.com> <465F3E8C.10404@inria.fr> <1180660974.15528.126.camel@rosella.wigram> <465FAF0B.5060700@inria.fr> X-Google-Sender-Auth: bef0f9699e7e77bd X-Miltered: at discorde with ID 466029E8.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 abstraction:01 modular:01 ocaml:01 abstraction:01 predictable:01 compilation:01 functors:01 functors:01 compilation:01 predictable:01 penalties:98 penalties:98 cleanest:98 abstract:01 > MLton's strength is that you don't have to pay the price for abstraction, > i.e. cleaning up your program (by factorizing it or making it more modular) > does not degrade performance. I have no experience with MLton, but I don't > believe that performances are much more difficult to predict than with OCaml > (Stephen?). Performance is much more difficult to predict with MLton than with OCaml. Even worse, with whole-program optimization a small change in one part of the program can affect performance in another part. That having been said, I would gladly take that drawback in exchange for the benefits of whole-program optimization. Eliminating the price of abstraction causes a change in mindset that helps one to avoid the mistake of premature optimization and to worry more about correctness and getting the code done. Also, although the performance of MLton is less predictable, it's not like the generated code is sometimes twice as fast as it would be with separate compilation and sometimes twice as slow. In reality, it's always as fast, and often, when the optimizations kick in, it's significantly faster (2, 3, 5 times). BTW, I'm not specifically comparing OCaml and MLton here -- I'm making the general observation that whole-program optimization adds optimization opportunities. Defunctorization is one example of the many whole-program optimizations in MLton that allow more abstract code without penalties. To answer a couple other questions on the list -- defunctorization can indeed give significant performance improvements, and after defunctorization, there are no performance penalties left from modules (indeed, there are no modules left :-). Also, the performance penalty at Jane Street (and other places) from functors is real, and causes people to rewrite code, manually duplicate code, etc. And, it prevents people from using functors in the first place, because they have a (conscious or unconscious) understanding of the cost. Unpredictable performance is a fact of life with computers. It's not possible to eliminate it, even with a sufficiently simple compilation approach. There are way too many other factors. I think it's better to encourage people to program in the cleanest way possible, and then to profile and improve their code if necessary. The same arguments that one can make for simple compilation strategies leading to predictable performance could be used to argue that we should all program in C or in assembly.