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 DF69EBC6B for ; Fri, 17 Aug 2007 07:42:53 +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 l7H5gpQq004222 for ; Fri, 17 Aug 2007 07:42:52 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGnQxEZ5LGJp/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.19,273,1183300200"; d="scan'208";a="174354785" 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 15:12:42 +0930 Subject: Re: [Caml-list] JIT VM in OCaml: Impossible? From: skaller To: Erick Tryzelaar Cc: Taras Glek , Caml List In-Reply-To: <46C51175.6000208@dslextreme.com> 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> <1187319000.29691.24.camel@rosella.wigram> <46C51175.6000208@dslextreme.com> Content-Type: text/plain Date: Fri, 17 Aug 2007 15:42:40 +1000 Message-Id: <1187329360.29972.26.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46C5355B.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compiler:01 caching:01 runtime:01 bytecode:01 bytecode:01 compilation:01 compilation:01 runtime:01 encodings:01 compiler:01 ocaml:01 ocamlopt:01 model:01 trivial:01 On Thu, 2007-08-16 at 20:09 -0700, Erick Tryzelaar wrote: > > 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. > > > > For loose definitions of JIT :) It doesn't do runtime optimization of > the code, of course. > > And to be fair, since whole program optimization needs to start roughly > from scratch every time, you can have some ugly compile times. Bytecode has to be compiled too. If you have a one-off script which doesn't benefit from optimisation much, then it is a toss up whether a bytecode compilation followed by JIT based machine code generation has higher cost than C code generation followed by C compilation. If the code has to run for a long time, or be re-run often, then the C compilation wins hands down. you would need a VERY sophisticated JIT to actually use runtime information to tune code generation, beyond 'it got used at least once' of course. OTOH traditional compilers can apply all sorts of static analysis driven optimisations a JIT cannot, because it is looking at a bigger picture. So roughly my feeling is that JIT offers NO performance advantages. It's the worst possible combination you can have. The advantage of JIT is that you can improve the performance of a VM when you have to use a VM either because you're stuck using rubbish like JVM for political reasons, or you need to maintain a secure, restricted environment, for example running scripts from a web-server. In the latter case a properly designed language translator can make the same guarantees, but correctness of translator based security assurance is probably harder to demonstrate than for a VM. I do agree a *sophisticated* JIT could outperform compiled native code IF it were able to dynamically generate code based on real time feedback from actually running code, but this is a VERY difficult job *especially* with modern processors which already do exactly this kind of thing with branch prediction etc: the JIT now has to second guess the CPU circuitry to be able to calculate alternative encodings. In some sense I make the argument strongly AGAINST VM implementations. I would argue *source code* is the proper object to execute, and a traditional compiler driven by changes to the source is the correct way to execute source: binary code should be regarded as a cache, not the final product. It's clear that this is entirely possible for Ocaml with a suitable harness and minor language tweaks: Ocamlopt.opt is very fast and Ocaml sources are quite portable, so executing Ocaml *source* code is the proper model of program execution -- the native code compilation should be regarded just like a JIT optimisation. The biggest obstacle here is the trivial lack of a proper language construction to state dependencies, and a proper packaging model. Felix does this right. Ocaml (with Ocamldep and some fiddling) could do it too. With such a program for Ocaml, Debian packagers would be ecstatic -- no more binaries. Just distribute and execute source. BTW: AFAICS Alain Frisch patch to run ocamltop as native code with native code dynamic loading comes very close to realising this. -- John Skaller Felix, successor to C++: http://felix.sf.net