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.0 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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id CFBFABC69 for ; Fri, 17 Aug 2007 04:50:10 +0200 (CEST) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7H2o843007731 for ; Fri, 17 Aug 2007 04:50:09 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALepxEZ5LGJp/2dsb2JhbAAN X-IronPort-AV: E=Sophos;i="4.19,273,1183300200"; d="scan'208";a="174258589" Received: from ppp121-44-98-105.lns10.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.98.105]) by ipmail01.adl2.internode.on.net with ESMTP; 17 Aug 2007 12:20:02 +0930 Subject: Re: [Caml-list] JIT VM in OCaml: Impossible? From: skaller To: Taras Glek Cc: Caml List In-Reply-To: <46C491E8.9010007@shaw.ca> References: <5C180944-2CD9-48FB-8802-8AF57972AD2C@gmail.com> <4DB2486A-4E68-4843-A02C-B058DB2CA28D@mac.com> <1187285851.6017.17.camel@rosella.wigram> <46C491E8.9010007@shaw.ca> Content-Type: text/plain Date: Fri, 17 Aug 2007 12:50:00 +1000 Message-Id: <1187319000.29691.24.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46C50CE0.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 toolchain:01 compiler:01 bytecode:01 compiler:01 caching:01 bloody:98 sourceforge:01 wrote:01 binaries:01 compile:01 parsing:01 compiles:01 compiles:01 caml-list:01 On Thu, 2007-08-16 at 11:05 -0700, Taras Glek wrote: > > The question is: why would you do this? Why not just generate > > C (or C++ as Felix does) and compile it to a shared library, > > then link and execute it? > > > Because that would be bloody slow and depend on having a toolchain > installed? For a JIT you want a fast compiler that only compiles as > little as is needed. Yes, it does depend on having a tool. Slow? No, not really: [AMD64 2300 1G]: (includes parsing the file) skaller@rosella:/work/felix/svn/felix/felix/trunk$ time f hello Hello World real 0m2.073s user 0m1.972s sys 0m0.084s (using cached parse) skaller@rosella:/work/felix/svn/felix/felix/trunk$ time f hello Hello World real 0m1.026s user 0m0.908s sys 0m0.100s (using cached binary) skaller@rosella:/work/felix/svn/felix/felix/trunk$ time flx hello Hello World real 0m0.039s user 0m0.016s sys 0m0.012s I suspect this is actually faster than any JIT, and there's no question it is faster if the program is reused. Don't forget: a program has to be compiled one way or the other. Even Python is compiled to bytecode. The tool above (Felix) is better than a JIT because it does whole program optimisation, generates machine binaries. So I don't buy 'slow' as an argument: the technique is much FASTER than any JIT system in all aspects, in fact it IS a JIT compiler -- it just compiles the whole program all the way from source with disk based caching which persists over invocations. -- John Skaller Felix, successor to C++: http://felix.sf.net