From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <fabrice.le_fessant@inria.fr>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id AE09ABC58
	for <caml-list@yquem.inria.fr>; Thu, 16 Sep 2010 11:08:54 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.56,375,1280700000"; 
   d="scan'208";a="57358508"
Received: from peermanence.saclay.inria.fr (HELO [195.83.212.205]) ([195.83.212.205])
  by mail3-relais-sop.national.inria.fr with ESMTP; 16 Sep 2010 11:08:54 +0200
Message-ID: <4C91DDE0.2040105@inria.fr>
Date: Thu, 16 Sep 2010 11:05:36 +0200
From: Fabrice Le Fessant <fabrice.le_fessant@inria.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826 Thunderbird/3.0.7
MIME-Version: 1.0
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Compiling Ocaml sources to c sources
References: <4C8F660B.4060901@telecom-bretagne.eu>	<20100914124341.GA11500@hector.lesours>	<004b01cb54fc$9c435020$d4c9f060$@com>	<AANLkTikCVkjQ7n0MX2AkabggXCMEC5924Jooo3RJMsNA@mail.gmail.com>	<006a01cb5515$c9c42420$5d4c6c60$@com> <AANLkTi=PiMun_kHtKLw4aWN42dm_Eynx188n4z6spUKO@mail.gmail.com>
In-Reply-To: <AANLkTi=PiMun_kHtKLw4aWN42dm_Eynx188n4z6spUKO@mail.gmail.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; ocaml:01 compiler:01 reimplement:01 ocaml:01 appending:01 bytecode:01 eray:01 ozkural:01 compiler:01 abstraction:01 garbage:01 wrote:01 caml-list:01 functions:01 compiling:02 

The problem is still the same: even if the code is compiled by a C
compiler, there is still the need for the garbage collector. If you
don't provide your own conservative GC (for which you would have to
reimplement all the native functions of OCaml), then you need to use
OCaml GC, and you would have to disable most optimizations to be sure
that the GC knows where to find live references. At the end, you would
get almost no performance improvement, compared to just appending the
assembly code for each bytecode instruction (see Piumarta's work in
PLDI'98).

--Fabrice

Eray Ozkural wrote, On 09/16/2010 02:38 AM:
> Well, what I would do is to apply a fully optimizing compiler from a
> proper hardware abstraction layer, whether it is JIT is irrelevant, but
> I do not see why the system would not start doing this as soon as the
> code is loaded in some place (and not when it starts to run). What is
> certain is that some simple transformation will not speed things up much.