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.6 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 1C872BBC4; Mon, 30 Mar 2009 17:42:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUDACaF0Elb0a8ZjGdsb2JhbACWBwEBAQoLCgcQtWaDegY X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="26643648" Received: from mail.motion-twin.com ([91.209.175.25]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 30 Mar 2009 17:42:48 +0200 Received: from [82.233.72.200] (helo=[192.168.2.159]) by mail.motion-twin.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LoJdI-0007FP-O2; Mon, 30 Mar 2009 17:42:44 +0200 Message-ID: <49D0E86E.9000307@motion-twin.com> Date: Mon, 30 Mar 2009 17:42:38 +0200 From: Nicolas Cannasse User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Xavier Leroy Cc: Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Google summer of Code proposal References: <200903211439.47107.cdome@bk.ru> <49C79A54.5020406@inria.fr> <200903231938.04825.jon@ffconsultancy.com> <49C8FEAA.6090302@inria.fr> In-Reply-To: <49C8FEAA.6090302@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; cannasse:01 ncannasse:01 motion-twin:01 ocaml's:01 ocaml:01 compiler:01 coq:01 compiler:01 inlining:01 ocaml:01 runtime:01 lacks:01 runtime:01 ffi:01 callbacks:01 Xavier Leroy a écrit : >>> 2- OCaml's strategy is close to optimal for symbolic computing. >> >> Is MLton not several times faster than OCaml for symbolic computing? > > No, only in your dreams. If there was a Caml or SML compiler that was > twice as fast as Caml on codes like Coq or Isabelle/HOL, everyone (me > included) would have switched to that compiler a long time ago. > MLton can probably outperform Caml on some symbolic codes, but not by > a large factor and not because of data representation strategies (but > rather because of more aggressive inlining and the like). I agree that OCaml runtime representation is already pretty good, although it lacks some runtime inspection abilities. IMHO, the main optimization that using LLVM can perform wrt OCaml internal representation is the ability to fully unbox floats, including for FFI callbacks. Of course, that might not help much for symbolic processing... As for 5 years for designing a whole system, thanks to today great tools (which OCaml is part of), I was myself able to build a complete ecosystem with haXe http://haxe.org and NekoVM in "only" 2 years, I'm pretty sure this can be done much faster when people know exactly what they are doing on how they want to get there. Best, Nicolas