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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 8F6BBBC58 for ; Thu, 16 Sep 2010 12:46:18 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEBAM6RkUzRVda0kGdsb2JhbACTaIV/AYgICBUBAQEBCQkMBxEDH6UEiTeCFIZqLYhUAQEDBYU8BIFagmuFZw X-IronPort-AV: E=Sophos;i="4.56,376,1280700000"; d="scan'208";a="57365523" Received: from mail-iw0-f180.google.com ([209.85.214.180]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Sep 2010 12:46:17 +0200 Received: by iwn8 with SMTP id 8so1399395iwn.39 for ; Thu, 16 Sep 2010 03:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2KQ0Vhhei+4KHltN1bc1+g15lEMJvVKKKy2l1/A95QQ=; b=w0jjy042thruCtYLkhVNpq9DuFM6IrpGnsLvqB3yavuvKxQv/UPkymSRkbqmo8TG4B y8vXukDdbZLVDUgMWDccmAnhM64GNKe3HhChUCrfUwg/tRa3+OL9A0vGWkuBY68mqwaZ oxuKTTrN6UUq4UDkqc+cSvVKk+RuHg2TeUdQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VtLj9bR2rGjEs5Uhj5z1YnYjuNH/B/y8+asDnZKO7iGM8bm/JXpF7DwpjqKPnh3xkc 7fXbpebJ2cBRRTiB74lhmiHOPotNJ3e0vzrp/Ups8cgB8kTd8GHUmX/m5Fq5aZV7fAba 3kDqZgNx57PcPyr7DpX3myzHvRe2luroLLMAs= MIME-Version: 1.0 Received: by 10.231.159.203 with SMTP id k11mr3170149ibx.115.1284633975683; Thu, 16 Sep 2010 03:46:15 -0700 (PDT) Received: by 10.231.159.131 with HTTP; Thu, 16 Sep 2010 03:46:15 -0700 (PDT) In-Reply-To: <4C91DDE0.2040105@inria.fr> 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:46:15 +0300 Message-ID: Subject: Re: [Caml-list] Compiling Ocaml sources to c sources From: Eray Ozkural To: Fabrice Le Fessant Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=005045015627c9c85f04905e2710 X-Spam: no; 0.00; ocaml:01 eray:01 ozkural:01 ocaml:01 boehm:01 compiler:01 compiler:01 bytecode:01 hypothetical:01 reimplement:01 appending:01 bytecode:01 eray:01 ozkural:01 abstraction:01 --005045015627c9c85f04905e2710 Content-Type: text/plain; charset=ISO-8859-1 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 < fabrice.le_fessant@inria.fr> 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. > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct --005045015627c9c85f04905e2710 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 com= piler),
do you mean that one would have to disable most optimizat= ions 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 a= ble to learn from actual=A0
ocaml compiler writers, BTW, your com= ments are much appreciated.

Regards,

= On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant <= fabrice.le_fessant@inria.fr<= /a>> 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, bu= t
> I do not see why the system would not start doing this as soon as the<= br> > code is loaded in some place (and not when it starts to run). What is<= br> > certain is that some simple transformation will not speed things up mu= ch.




--
Eray Ozkura= l, PhD candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/g= roup/ai-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--005045015627c9c85f04905e2710--