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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 14F18BC69 for ; Fri, 1 Jun 2007 16:37:26 +0200 (CEST) Received: from smtp.janestcapital.com (www.janestcapital.com [66.155.124.107]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l51EbOGW027091 for ; Fri, 1 Jun 2007 16:37:25 +0200 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id AF2F0368; Fri, 01 Jun 2007 10:37:35 -0400 Message-ID: <46602F21.5080503@janestcapital.com> Date: Fri, 01 Jun 2007 10:37:21 -0400 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Weeks Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics 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> <604682010706010715t7d7e503bm82a817338685b9f8@mail.gmail.com> In-Reply-To: <604682010706010715t7d7e503bm82a817338685b9f8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 46602F24.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compilation:01 predictable:01 ocaml:01 compilers:01 wrote:01 caml-list:01 seems:03 tricky:04 comparison:04 brian:04 brian:04 implement:06 inria:06 implementing:06 Stephen Weeks wrote: > 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. What's humorous about this statement is that most C compilers now are implementing a lot of these fancy optimizations, even whole-program optimizations (see LLVM), which makes predicting their performance equally tricky to predict. I think the real reason Ocaml doesn't have advanced optimizations and whole program analysis is just one of time vr.s value. It hasn't been valuable enough to someone yet to take the time and put in the work to implement them. The position of most people on this list, including INRIA, seems to be "it'd be nice, and we'd definately use it if it were available, but at the moment we're doing something more important/more interesting/else..." Brian