From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id CE604BBAF for ; Sat, 28 Feb 2009 22:47:03 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAN8/qUnUnwdjjmdsb2JhbACCKJI7AQEBAQkLCAkPBsF9hBoG X-IronPort-AV: E=Sophos;i="4.38,282,1233529200"; d="scan'208";a="24852126" Received: from relay.pcl-ipout01.plus.net ([212.159.7.99]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Feb 2009 22:47:03 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4FAN8/qUnUnw6S/2dsb2JhbACCKNR2hBoG Received: from ptb-relay02.plus.net ([212.159.14.146]) by relay.pcl-ipout01.plus.net with ESMTP; 28 Feb 2009 21:47:03 +0000 Received: from [87.112.14.152] (helo=leper.local) by ptb-relay02.plus.net with esmtp (Exim) id 1LdX1S-0006dB-Mz for caml-list@yquem.inria.fr; Sat, 28 Feb 2009 21:47:02 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Odd performance result with HLVM Date: Sat, 28 Feb 2009 21:52:18 +0000 User-Agent: KMail/1.9.9 References: <200902280112.24115.jon@ffconsultancy.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902282152.18430.jon@ffconsultancy.com> X-Plusnet-Relay: d769e37877499a46ace4be7402d72ea2 X-Spam: no; 0.00; high-level:01 ocaml:01 low-level:01 ocaml-like:01 ocamlopt:01 ocamlopt:01 compilation:01 run-time:01 compilation:01 polymorphism:01 datatypes:01 malloc:01 ocaml:01 invokes:01 bytecode:01 On Saturday 28 February 2009 20:18:40 Kuba Ober wrote: > You didn't let us in on how it really works. You said "high-level > virtual machine > built upon LLVM and written in OCaml". LLVM means too many things to be > able to decipher what you mean, and your statement is too general. I'm referring to my HLVM project that I described here: http://flyingfrogblog.blogspot.com/2008/12/building-better-future-high-level.html That is built upon the Low-Level Virtual Machine here: http://llvm.org Basically, my idea is to build a better VM for OCaml-like languages. My work is still at a very early stage of development but the results are already promising: faster than ocamlopt on all of my benchmarks and several times faster on some numerical benchmarks. There are really two major advantages over the current ocamlopt design and both stem from the use of JIT compilation: . Run-time types allow per-type functions like generic pretty printers and comparison. . Monomorphisation during JIT compilation completely removes the performance cost of polymorphism, e.g. floats, tuples and records are never boxed. Algebraic datatypes were the latest addition and I expected them to be very slow because I am calling thread-safe malloc every time one is created. However, a simple benchmark that creates and folds over a huge list actually runs faster on my HLVM than it does in OCaml. > I'm assuming, but that's forced, so don't shoot if I make an asinus > out of myself ;) > > So, it's a VM and it runs native jit-ted code like say .net would. So > presumably you > have some OCaml code that then invokes jit and some native functions > to dispatch > to jit-ted code? Yes. > Do you interpret any bytecode, or always compile? Always compile. > Do > you even > have to have any OCaml code running in the process where the jit-ted > code runs in? I believe the OCaml bindings to LLVM JIT compile a function, get a pointer to it and call into that function from the current thread. So there is no process separation. > I presume you use the LLVM infrastructure to do the jit-ting, but > without knowing > exactly what code runs in the process space of the application, it's > hard to tell > what's going on. You just gave me another idea: use LLVM to compile the same IR code to a standalone executable and benchmark that. I'll get back to you... > There's no floating point state to change that would slow things up > that much. > At least I have never seen anything like that. That's what I thought. > Maybe the FP exceptions are being fired somehow? Maybe something like that. I have no idea. This definitely only affects float performance so it is not a difference in the efficiency of calling into JIT compiled code from OCaml bytecode or native code. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e