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 B68E4BC57 for ; Tue, 16 Nov 2010 18:32:12 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoCAChP4kzRVde0kGdsb2JhbACUX414CBUBAQEBCQkMBxEDH6Vki3oBBY4YAQSFSw X-IronPort-AV: E=Sophos;i="4.59,206,1288566000"; d="scan'208";a="79058790" Received: from mail-ey0-f180.google.com ([209.85.215.180]) by mail2-smtp-roc.national.inria.fr with ESMTP; 16 Nov 2010 18:32:12 +0100 Received: by eyf18 with SMTP id 18so434285eyf.39 for ; Tue, 16 Nov 2010 09:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:reply-to :content-transfer-encoding:message-id:references:to:x-mailer; bh=bx/pt7LH6QVzfbIy36LQ0aJ/I+tZzvvizhgrHulkBwI=; b=cPHLH2shbTXUGl9XpqYJ5EtF1QWBThRxRCph8o24ewcNgCzBBO69M8Ro7LP7XzduYX NDej6qxbic0Dj3/H5kBcZnDgUja1sEKx4lzNNK0FCfVN/IDlDWu0ptWaVJBGCbsZFENv kyZjWkci0wjErWdtfkuR+EvSmPxuC6917QXvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:reply-to :content-transfer-encoding:message-id:references:to:x-mailer; b=B4xvtGrsXlqbSereT8kAlc7a8lCClaBk08PPldfk3lvMXCOW/hjxfEPfTlTeOvOSXv 3j5AEhUPAC5eG3Y58+8AgBfAZGJJYTlaP988yQo/ujWpR0quXMD7Sw5DCcX1FzvAsN0N VYE3bXgjQ6RuCT1xxNnZ8NKRIW/IsED7QLEoQ= Received: by 10.213.8.67 with SMTP id g3mr5962258ebg.38.1289928732144; Tue, 16 Nov 2010 09:32:12 -0800 (PST) Received: from bespin.kosmos.all (ip-95-223-170-32.unitymediagroup.de [95.223.170.32]) by mx.google.com with ESMTPS id x54sm1333570eeh.17.2010.11.16.09.32.10 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 09:32:11 -0800 (PST) Subject: Re: [Caml-list] OCamlJit 2.0 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Benedikt Meurer In-Reply-To: Date: Tue, 16 Nov 2010 18:32:09 +0100 Reply-To: caml-list@yquem.inria.fr Content-Transfer-Encoding: quoted-printable Message-Id: References: To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; basile:01 bytecode:01 suboptimal:01 bytecode:01 compilation:01 ocamlrun:01 ocamlc:01 -help:01 ocamlc:01 -help:01 computations:01 byte-code:01 computations:01 ocamlopt:01 2.0:98 On Nov 16, 2010, at 18:07 , bluestorm wrote: > To those of you who are lazy but still curious, I just read the = report, and here are the answers to the question I had: Thanks for posting these points, should have done this in my original = post... > 1. Is that project related to Basile Starynkevitch's venerable = OCamlJIT ? >=20 > Yes, OcamlJIT was apparently a major inspiration for this work. The = overall design is similar, and in particular the objective of absolute = compatibility with the existing bytecode (even when it may hurts = performances) was retained. Unfortunately, due to bitrotting and = different architectures (OcamlJIT x86 vs. OcamlJIT2 x86_64), there is no = direct performance comparison, though the reports seems to indicate = similar to better performances. Several points were also improved = (better (but still suboptimal) register usage, clever hacks to speed up = mapping between bytecode and native code adresses...). With the x86 port being close to complete, direct comparison with = OcamlJIT will be possible (dunno if OcamlJIT will work with 3.12 tho). = I'll do appropriate comparisons once everything is in place. > 2. Does it use LLVM ? >=20 > No, it doesn't, but it's justified. Apparently, an early prototype = showed than LLVM compilation/generation overhead was too high. A = (debatable) design goal of OcamlJIT2.0 is to be absolutely faster than = ocamlrun, even on *very* short-running programs (`ocamlc -help`). This is indeed debatable, atleast for "ocamlc -help". But this was not = the main concern with LLVM. LLVM overhead is acceptable for long running = computations, but everything else is slowed down noticably. It should = also be noted that my LLVM prototype was rather quick&dirty, so it may = indeed be possible to get a LLVM based JIT which is on par with the = byte-code interpreter for common applications. But why would one want to = do this? Long running computations can be speed up very well using = ocamlopt (no need to perform them using the interactive top-level). > OCamlJIT2.0 uses its own macro to generate x86_64 assembly directly = (apparently using a dedicated library wasn't worth it). A drawback of = this strategy is its inherent non-portability. It used AsmJit before, which is also limited to x86/x86-64; the = non-portability is actually a design decision (as explained in my = original post, portability to non-desktop machines was not a goal for = the current implementation). HTH, Benedikt Meurer=