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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id E505EBC57 for ; Tue, 30 Nov 2010 19:28:16 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYDAIHR9EzCT4aYg2dsb2JhbACjKQEBAQoJDBgixC+CE4M0BIUxizI X-IronPort-AV: E=Sophos;i="4.59,281,1288566000"; d="scan'208";a="82014705" Received: from smtp-152-tuesday.nerim.net (HELO maiev.nerim.net) ([194.79.134.152]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Nov 2010 19:28:09 +0100 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by maiev.nerim.net (Postfix) with ESMTPS id 04B432E023; Tue, 30 Nov 2010 19:28:09 +0100 (CET) Received: from glinka.lesours ([192.168.0.1]) by hector.lesours with smtp (Exim 4.72) (envelope-from ) id 1PNUvw-0002FC-AL; Tue, 30 Nov 2010 19:28:08 +0100 Date: Tue, 30 Nov 2010 19:27:58 +0100 From: Basile Starynkevitch To: =?ISO-8859-1?Q?T=F6r=F6k?= Edwin Cc: bluestorm , caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT Message-Id: <20101130192758.6173bb4f.basile@starynkevitch.net> In-Reply-To: <20101130192600.35698cde@deb0> References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> <20101130192600.35698cde@deb0> X-Mailer: Sylpheed 3.1.0beta2 (GTK+ 2.22.0; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; basile:01 basile:01 gcc:01 ocaml:01 gcc:01 ocaml:01 ocamlopt:01 compiler:01 compiler:01 runtime:01 ocamlopt:01 damien:01 weis:01 runtime:01 cheers:01 On Tue, 30 Nov 2010 19:26:00 +0200 T=F6r=F6k Edwin wrote: >=20 > Well there could also be a GCC backend for OCaml, but I don't know how > one should get started writing one (or if it would be worth it). Since I worked on OcamlJIT1 and since I am working now on GCC (actually, mostly on the GCC MELT branch, see www.gcc-melt.org for more, but sometimes on the GCC trunk, e.g. its gengtype generator), I probably have some personal ideas [e.g. my opinions only] on that. However, I am not crazy enough to work on an Ocaml front-end to GCC! The current (slow) trend inside GCC is to open & stabilize more and more its middle-end. In particular, the GCC middle end internal representations (which you can work on using MELT, a Lispy domain specific language suited for that very purpose) such as Gimple (and Tree) are becoming more stable, and will eventually (I don't know how and when and by whom!) have a "front-end", that is a program eating a textual representation of Gimple code and building from it Gimple internal representation in GCC memory. So in the long term, the GCC internal Gimple language is becoming more stable and will have a textual front-end. It will then becomes quite similar to the LLVM input language http://llvm.org/docs/LangRef.html. When that happens, one could imagine that ocamlopt (or some other program) will have the ability to generate (in textual files) the appropriate representations of the Ocaml code it is compiling. One could also imagine that in the long term, GCC would provide enough plugin hooks to plug a full (nearly arbitrary) front-end inside it. If that happens, one could imagine an Ocaml compiler, implemented as a gcc-ocaml-frontend.so plugin, which would create Gimple internals from Ocaml code. However, I believe no one is interested to work on that, and this is probably the case because Ocaml is "fast-enough" for most cases. Ocaml major strength is the power and expressiveness of its source language. My feeling is that Ocaml is more targetted for people requiring developers' productivity, while GCC is a mature industrial compiler aiming portability and performance of generated binary programs, coded in old [ugly] languages like C or C++. I am not sure that putting a lot of efforts inside the Ocaml compiler, to slightly improve the performance of generated executable, is worthwhile (in particular, because the runtime & the GC may become a bottleneck w.r.t to minor performance improvement of ocamlopt generated binaries). I would bet that would bring less than 20% improvement at most (and often, much less), for a quite high labor cost. And my personal feeling is that these days, bright Gallium people (like Xavier Leroy or Fran=E7ois Pottier and their colleagues) and other Inria persons related to Ocaml (like Damien Doligez or Pierre Weis and many others) are much more interested in bringing formal methods inside compilers (e.g. the Compcert project of a certified & "proved" C compiler) than in spending a lot of time to improve ocamlopt generated code by a few percents.=20 I would prefer them to improve even more the Ocaml language (e.g. GADT...), perhaps to work on a parallel runtime (but we all now that is *very* hard and perhaps even boring), perhaps even to start working, as researchers, on the [incompatible] successor of Ocaml. As food for thought, I tend to believe that parallel computers (e.g. "clouds", or just our next desktop with 16 cores) will require another programming style and another programming language, and that incrementally improving Ocaml for such systems is not enough. Some people will have to invent another way of thinking and programming these parallel systems, and it might be the same people who brought us Ocaml! But all this is day-dreaming, I have no real ideas, just personal wishes (and a big admiration for all the Ocaml people at INRIA, which are *researchers* not random software developers). Cheers --=20 Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***