From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 799EABC58 for ; Thu, 16 Sep 2010 13:11:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJuYkUzRVdg0kGdsb2JhbAChcQgVAQEBAQkJDAcRAx+kc4tLhmaJAQEBAwWFPASKLIVfgyE X-IronPort-AV: E=Sophos;i="4.56,376,1280700000"; d="scan'208";a="67690185" Received: from mail-qw0-f52.google.com ([209.85.216.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 16 Sep 2010 13:11:30 +0200 Received: by qwf6 with SMTP id 6so1197055qwf.39 for ; Thu, 16 Sep 2010 04:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=A1F9FXQieenL5AJKDFoYM4pGxdo/6zjkqa3ngfJg8gA=; b=rGdGGHxkgQMbqCkv0dZTn4Ndz9VhHTDlxuvdwxGai6o0vGTuqKM7YjnCSodCWSlunG BhjKKBSgad10LixnW96HIoYQTJ5OZU0d0ptGviK2iu1XKBnH/udFe4r33KtjG4P1cmAk sQi4Y8Sy1MOT7nfU9QcUsa0At16ohmeRtY7AM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=TwHUCPuG5AO+BF7yfesNRav7KCXTBYvu3c/WNFWBsS1vko5c3QN5N4G1iEVnM1qufm HYatGa4LHGXKFtC4JBmt3NDJBDvdb6sPl5CIPfMuptm5XNOlK8kLSJqkMORqjx30MAmL FIZch1qqvq42dA8GoBWZkvOvNnFHjQwZrw/24= MIME-Version: 1.0 Received: by 10.229.250.193 with SMTP id mp1mr2143320qcb.129.1284635490351; Thu, 16 Sep 2010 04:11:30 -0700 (PDT) Sender: fabrissimo@gmail.com Received: by 10.229.48.85 with HTTP; Thu, 16 Sep 2010 04:11:29 -0700 (PDT) In-Reply-To: References: <4C8F660B.4060901@telecom-bretagne.eu> <20100914124341.GA11500@hector.lesours> <004b01cb54fc$9c435020$d4c9f060$@com> <006a01cb5515$c9c42420$5d4c6c60$@com> <4C91DDE0.2040105@inria.fr> Date: Thu, 16 Sep 2010 13:11:29 +0200 X-Google-Sender-Auth: VOt93bO7vqAG7tQXuCs4cpjemYA Message-ID: Subject: Re: [Caml-list] Compiling Ocaml sources to c sources From: Fabrice Le Fessant To: Eray Ozkural Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; ocaml:01 bigloo:01 compiler:01 ocaml's:01 ocaml's:01 pointer:01 ocaml:01 pointers:01 compiler:01 pointers:01 computations:01 dependencies:01 bytecode:01 bytecode:01 eray:01 You could use Boehm's garbage-collector for such a project, indeed, that's what is done in Bigloo, to compile Scheme programs to C. Since Boehm's GC is conservative, it would probably work well in such a system, with or without compiler optimizations, but the GC itself would probably be much slower than OCaml's GC on monothreaded code. On the contrary, OCaml's GC is not conservative, so it really needs to know what is a pointer to OCaml data, and also to be warned when pointers to OCaml data are erased (what caml_modify does). If you leave the C compiler perform all its optimizations, you might end up with pointers to OCaml data that are not where they should be (typically, it can duplicate a variable to parallelize some computations when there are no dependencies between them, and the GC will only scan one of them). So, you have to limit the C compiler to only "safe" optimizations from that point of view. By the way, there are almost no optimizations performed in the Ocaml compiler on bytecode, most of the interesting ones are only performed in the native compiler. I think the philosophy behind this choice is that you want to compile very fast to bytecode (so, no time for optimization), and only use the native code compiler at the end for efficient code. --Fabrice On Thu, Sep 16, 2010 at 12:46 PM, Eray Ozkural wrote: > Yes, I've seen how wired the GC is in the ocaml sources. I had used the > Boehm GC in a compiler project (not for the generated code but the > compiler), > do you mean that one would have to disable most optimizations in the ocaml > bytecode > compiler to make such a hypothetical bytecode-to-C compiler work with a C > GC, or am I missing something crucial? It's great to be able to learn from > actual > ocaml compiler writers, BTW, your comments are much appreciated. > Regards, > On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant > wrote: >> >> 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. >>