caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Basile Starynkevitch <basile@starynkevitch.net>
To: "Török Edwin" <edwintorok@gmail.com>
Cc: bluestorm <bluestorm.dylc@gmail.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
Date: Tue, 30 Nov 2010 19:27:58 +0100	[thread overview]
Message-ID: <20101130192758.6173bb4f.basile@starynkevitch.net> (raw)
In-Reply-To: <20101130192600.35698cde@deb0>

On Tue, 30 Nov 2010 19:26:00 +0200
Török Edwin <edwintorok@gmail.com> wrote:
> 
> 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çois 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. 

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

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


  reply	other threads:[~2010-11-30 18:28 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-30  8:36 Benedikt Meurer
2010-11-30 10:48 ` [Caml-list] " Török Edwin
2010-11-30 10:55   ` Benedikt Meurer
2010-11-30 17:01     ` bluestorm
2010-11-30 17:26       ` Török Edwin
2010-11-30 18:27         ` Basile Starynkevitch [this message]
2010-11-30 17:29       ` Benedikt Meurer
2010-11-30 17:32       ` Yoann Padioleau
2010-11-30 22:06         ` Jon Harrop
2010-11-30 22:48           ` Benedikt Meurer
2010-12-01 14:11             ` Jon Harrop
2010-12-01 15:00               ` Benedikt Meurer
2010-12-01 22:03                 ` Jon Harrop
2010-12-02  1:17                   ` Eray Ozkural
2010-12-03 10:03                   ` ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT) Benedikt Meurer
2010-12-03 13:34                     ` Till Varoquaux
2010-12-03 13:41                       ` Eray Ozkural
2010-12-03 14:06                         ` Török Edwin
2010-12-03 21:16                       ` Jon Harrop
2010-12-05 16:44                       ` Benedikt Meurer
2010-12-03 14:32                     ` Philippe Strauss
2010-12-03 21:22                       ` Jon Harrop
2010-12-03 21:45                         ` Philippe Strauss
2010-12-03 15:32                     ` Michael Ekstrand
2010-12-03 21:34                       ` Jon Harrop
2010-12-03 20:07                     ` Jon Harrop
2010-12-05 16:37                       ` Benedikt Meurer
2010-12-05 16:57                         ` Török Edwin
2010-12-05 20:54                           ` Benedikt Meurer
2010-12-05 20:12                         ` Jon Harrop
2010-12-05 21:21                           ` Benedikt Meurer
2010-12-05 21:44                             ` Benedikt Meurer
2010-12-06 22:38                             ` Jon Harrop
2010-12-05 22:41                           ` Erik de Castro Lopo
2010-12-05 22:34                         ` Erik de Castro Lopo
2010-12-06  8:27                           ` Benedikt Meurer
2010-12-06  9:28                             ` David Rajchenbach-Teller
2010-12-06 11:08                         ` Richard Jones
2010-12-06 20:18                           ` Jon Harrop
2010-12-01  0:16           ` [Caml-list] OCamlJIT2 vs. OCamlJIT Erik de Castro Lopo
2010-12-01  1:34             ` Yoann Padioleau
2010-12-01 12:58             ` Jon Harrop
2010-12-01 13:55               ` ivan chollet
2010-11-30 21:19       ` Jon Harrop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101130192758.6173bb4f.basile@starynkevitch.net \
    --to=basile@starynkevitch.net \
    --cc=bluestorm.dylc@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=edwintorok@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).