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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 728AFBC57 for ; Wed, 12 May 2010 07:51:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcBACre6UtbeblBmWdsb2JhbACePwEBAQEBCAsKBxEiuUiFEQQ X-IronPort-AV: E=Sophos;i="4.53,212,1272837600"; d="scan'208";a="62723868" Received: from 64.mail-out.ovh.net ([91.121.185.65]) by mail4-smtp-sop.national.inria.fr with SMTP; 12 May 2010 07:51:37 +0200 Received: (qmail 32149 invoked by uid 503); 12 May 2010 05:56:34 -0000 Received: from b9.ovh.net (HELO mail404.ha.ovh.net) (213.186.33.59) by 64.mail-out.ovh.net with SMTP; 12 May 2010 05:56:34 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 12 May 2010 05:51:35 -0000 Received: from 81-64-225-224.rev.numericable.fr (HELO ?192.168.0.10?) (forum%x9c.fr@81.64.225.224) by ns0.ovh.net with SMTP; 12 May 2010 05:51:35 -0000 Subject: Re: [Caml-list] [ANN] OCaml-Java project: 1.4 release Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: "forum@x9c.fr" In-Reply-To: Date: Wed, 12 May 2010 07:51:35 +0200 Cc: forum@x9c.fr Content-Transfer-Encoding: quoted-printable Message-Id: <22B48086-35DF-433A-A5FE-5A2E809ADB2C@x9c.fr> References: <82D5DCC1-EC03-4D0F-830A-6944E38DEF4F@x9c.fr> To: caml users X-Mailer: Apple Mail (2.1078) X-Ovh-Tracer-Id: 4748764332607800096 X-Ovh-Remote: 81.64.225.224 (81-64-225-224.rev.numericable.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Spam: no; 0.00; pointers:01 moderately:01 ocaml:01 async:01 recursion:01 compiler:01 ocaml:01 ocamlc:01 ocamllex:01 translated:01 labltk:01 ocamlc:01 ocamlopt:01 runtime:01 ocamlrun:01 Le 11 mai 2010 =E0 21:23, Warren Harris a =E9crit : > I'm curious whether there are any notes / pointers regarding the = completeness of the ocaml-java implementation (couldn't find this on the = web site). I'm wondering about the feasibility of using it for a = moderately large ocaml project I've been working on which uses Lwt to = perform async I/O. I assume that for this to work with ocaml-java, the = lowest levels of Lwt would need to be adapted to use NIO or threads in = order to run on a JVM. Also my application is written in a pure = functional style, and relies heavily on closures, currying, recursion = and the ability for the compiler to do tail call optimization. I'm = concerned that this will not translate well to Java. Here is some information about the OCaml-Java project (both current 1.4 release and future 2.0 release). Regarding compatibility with the original implementation of OCaml: - ocamljava is able to compile working versions of ocamlc, ocamllex, = menhir and itself, giving some confidence in its language-compatibility level; - all the libraries bundled with the original implementation have been = translated and tested through some unit testing (but thread libraries tests are = only lightweight, labltk support is based on the swank project [1], and unix is only = partially supported); - document [2] gives per-primitive compatibility information; - the last page of [3] lists the differences between ocamlc/ocamlopt = and ocamljava compilers; - third-party libraries (such as Lwt) should be supported = out-of-the-box as long as they do neither rely on exotic features (remember: "Obj.magic is not part of = the OCaml language"), nor on C code (unless you can translate it to Java code). Regarding performances in current version: - closures are based upon Java reflection (will be based upon JDK 7's = method handles, avoiding access checks on each call); - only "explicit self" tail calls are optimized ("self" meaning same = function, and "explicit" meaning "not through a closure"); - performances are terrible and memory consumption is excessive. Bottom line: the current version should be regarded as a = proof-of-concept. However, I have spent recent vacation on the upcoming 2.0 version, with = some positive results. The runtime has been partially rewritten, reducing memory = consumption and increasing performances. The Java equivalent of "ocamlrun" is now within = an order of magnitude from the original tool on all tested programs, and only about = 4 times slower on some (e. g. "nbody" from the language shootout [4]). This seems to indicate = that -when updated- the ocamljava compiler should be able to at least match ocamlc = performances. Notice that is a conservative statement / objective if you consider that = Scala is on par with ocamlopt on some benchmarks (but the Scala language has been designed = from the bottom up to be run on the JVM). A final word about tail call optimization. As previously said, only = "explicit self" calls are optimized (as far as I know, this is also true for mature compilers like = Scala or Clojure). This will not change in future versions, unless Sun / Oracle adds = support for tail calls in the JVM [5] [6]. I know that some people will regard a compiler for a functional language = with no general tail call optimization as "broken", but it is clear that OCaml-Java will = not perform program transformations (such as trampolining) to enable tail call optimization = in every cases. My understanding may be incorrect, but it seems that such = transformations result in obfuscated code (hindering HotSpot JIT compilation) and unpredictable performances. Some points above may need to be elaborated, but this very message is = already quite long... Anyway, feel free to ask for further information. Regards, Xavier Clerc [1] http://www.onemoonscientific.com/swank/summary.html [2] http://cadmium.x9c.fr/distrib/cadmium-compatibility.pdf [3] http://cafesterol.x9c.fr/distrib/cafesterol.pdf [4] http://shootout.alioth.debian.org/ [5] http://openjdk.java.net/projects/mlvm/subprojects.html#TailCalls [6] http://wikis.sun.com/display/mlvm/TailCalls=