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 CD856BC57 for ; Tue, 30 Nov 2010 18:02:00 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgCABO99EzRVdg0kGdsb2JhbACbAgGICQgVAQEBAQkJDAcRAx+pQ4lkghiFRy6IVgEBAwWCDoM0BIpiiS4 X-IronPort-AV: E=Sophos;i="4.59,280,1288566000"; d="scan'208";a="68870563" Received: from mail-qw0-f52.google.com ([209.85.216.52]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Nov 2010 18:01:50 +0100 Received: by qwe4 with SMTP id 4so323579qwe.39 for ; Tue, 30 Nov 2010 09:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=pE4L0f2eTyj0ZwlxCyctQD60xHCgUZ7frVEJWoO+9Ds=; b=oJ6bJsNDF73KOclWXPl3wjKF/G67HW8EOSZnzAumQ9nrpwzpWXhbP+3aViWT9XTQAz ZzV+i3WBR+Fgm06ZcCw9m6ZFdrzitBj6X2MCNHVZndOzAMolqnhmsi1ij18JmlmQULYz 568Nx0lPDr63M4RCn0klBwMErX/Kh0PHtwpPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=rOEftfvTry3GXncp62VN0XHIOgkDlnmwwC+aTS81AREtLcDJ20VKyTicfvF3M/Lyi8 26yQlLoPMlJSoZ4sOcxSeCn6tAYbYWiJqfG4FA/eHMmW6Gp7oS7/jI7dVePzlGcSTjdJ EqBiyB/Fh2dA9PLRUGX5HVd7LJXrtatGSu/oo= Received: by 10.229.189.4 with SMTP id dc4mr6168037qcb.106.1291136508814; Tue, 30 Nov 2010 09:01:48 -0800 (PST) MIME-Version: 1.0 Sender: gabriel.scherer@gmail.com Received: by 10.229.253.135 with HTTP; Tue, 30 Nov 2010 09:01:28 -0800 (PST) In-Reply-To: References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> From: bluestorm Date: Tue, 30 Nov 2010 18:01:28 +0100 X-Google-Sender-Auth: jnguOUt22z5udq0W3YYEzHt7ytE Message-ID: Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT To: Benedikt Meurer Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=0016361e815cf6e591049648244a X-Spam: no; 0.00; ocamlopt:01 ulambda:01 byte-code:01 ocamlopt:01 low-level:01 ocaml:01 ocaml:01 bytecode:01 compiler:01 compiler:01 non-trivial:01 runtime:01 compilation:01 semantics:01 semantics:01 --0016361e815cf6e591049648244a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 30, 2010 at 11:55 AM, Benedikt Meurer < benedikt.meurer@googlemail.com> wrote: > > LLVM backend for ocamlopt is a totally different story. You'd have to start > with the Ulambda or the Cmm intermediate representation, while a JIT > approach starts with the byte-code representation (not necessarily, but that > was the case for our approach). > > However, I'm not sure there would be any immediate benefit from using LLVM > as code generator backend for ocamlopt, since ocamlopt already does a quite > good (and fast) job. So besides probably educational or research interests, > what would be the practical benefit of LLVM inside ocamlopt? > There would be several advantages in switching to LLVM for code generation. The general idea is that if other people work on the low-level stuff, it is less work for the OCaml implementors. - more portability : while I'm not sure LLVM is ported to more platforms than OCaml right now, the LLVM community will probably port its bytecode to numerous architectures in the future; in contrast, maintining numerous backend in the OCaml compiler has a maintainance cost. In particular, cross-compilation would probably be easier. - more optimizations : the LLVM guys try to develop a wide range of optimization passes between LLVM IR and native code, while ocamlopt is mostly a "non-optimising compiler". It's not clear however how much gain we could have, as OCaml has already optimized the most important parts, and a big part of the performance concerns are outside the LLVM area (data representation and GC). Still, the experience of GHC-LLVM has been quite positive, with noticeable improvements in some cases. On the other hand, it may be non-trivial to adapt LLVM to cope with the OCaml runtime, the GC in particuliar, and that would probably involve upstream changes to LLVM. LLVM is nice and trendy (though it's a shame the GNU guys, partly due to their own mistakes, are losing an important part of the FLOSS ecosystem to Apple...), but I'm personally more interested in the more theoretical projects of verified compilation toolchains, such as compcert ( http://compcert.inria.fr/ ). It's unrealistic to hope to have a completely verified ocaml-to-assembly compiler, as we would first need formal semantics for the OCaml language itself, but it is the very point : doing that kind of things forces you to have formal semantics, which is very interesting in many respects. Asking for a decent compiler was once the way to tell apart the serious languages from the insane string-fiddling script languages, but the line is blurred by the indecent amount of work injected in the optimization of those insane languages. Formal semantics will distinguish the gentlemen of the future. --0016361e815cf6e591049648244a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 30, 2010 at 11:55 AM, Benedikt Meure= r=A0<benedikt.meurer@googlemail.com>=A0wrote:
LLVM backend for ocamlopt is a totally different story. You'd have to s= tart with the Ulambda or the Cmm intermediate representation, while a JIT a= pproach starts with the byte-code representation (not necessarily, but that= was the case for our approach).

However, I'm not sure there would be any immediate benefit from usi= ng LLVM as code generator backend for ocamlopt, since ocamlopt already does= a quite good (and fast) job. So besides probably educational or research i= nterests, what would be the practical benefit of LLVM inside ocamlopt?

There would be several advantages in switc= hing to LLVM for code generation. The general idea is that if other people = work on the low-level stuff, it is less work for the OCaml implementors.

- more portability : while I'm not sure LLVM is por= ted to more platforms than OCaml right now, the LLVM community will probabl= y port its bytecode to numerous architectures in the future; in contrast, m= aintining numerous backend in the OCaml compiler has a maintainance cost. I= n particular, cross-compilation would probably be easier.

- more optimizations : the LLVM guys try to develop a w= ide range of optimization passes between LLVM IR and native code, while oca= mlopt is mostly a "non-optimising compiler". It's not clear h= owever how much gain we could have, as OCaml has already optimized the most= important parts, and a big part of the performance concerns are outside th= e LLVM area (data representation and GC). Still, the experience of GHC-LLVM= has been quite positive, with noticeable improvements in some cases.=A0

On the other hand, it may be non-trivial to adapt LLVM = to cope with the OCaml runtime, the GC in particuliar, and that would proba= bly involve upstream changes to LLVM.

LLVM is nice= and trendy (though it's a shame the GNU guys, partly due to their own = mistakes, are losing an important part of the FLOSS ecosystem to Apple...),= but I'm personally more interested in the more theoretical projects of= =A0verified compilation toolchains, such as compcert (=A0http://compcert.inria.fr/=A0). It's unrealisti= c to hope to have a completely verified ocaml-to-assembly compiler, as we w= ould first need formal semantics for the OCaml language itself, but it is t= he very point : doing that kind of things forces you to have formal semanti= cs, which is very interesting in many respects.

Asking for a decent compiler was once the way to tell a= part the serious languages from the insane string-fiddling script languages= , but the line is blurred by the indecent amount of work injected in the op= timization of those insane languages. Formal semantics will distinguish the= gentlemen of the future.
--0016361e815cf6e591049648244a--