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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 9F805BB9A for ; Sat, 22 Oct 2005 02:39:02 +0200 (CEST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j9M0d0pK001848 for ; Sat, 22 Oct 2005 02:39:01 +0200 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id j9M0chTV008297; Sat, 22 Oct 2005 09:38:43 +0900 (JST) Date: Sat, 22 Oct 2005 09:39:40 +0900 (JST) Message-Id: <20051022.093940.85425578.garrigue@math.nagoya-u.ac.jp> To: jonathan.roewen@gmail.com Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] The Bytecode Interpreter... From: Jacques Garrigue In-Reply-To: References: <3d13dcfc0510210427g5ea98df7s@mail.gmail.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 43598A24.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 bytecode:01 ocaml:01 bytecode:01 optimise:01 ocamlopt:01 ocaml:01 surprising:01 run-time:01 compiler:01 compiler:01 runtime:01 ocamlrun:01 compilers:01 runtime:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=DNS_FROM_RFC_ABUSE autolearn=disabled version=3.0.3 From: Jonathan Roewen > I've noted on the computer language shootout that ocaml bytecode is > slow compared to Java. I'm curious, are there any plans to optimise > the shit out of the bytecode interpreter? I know it has been a goal to > not be much more than 1.3x slower than C -- but this only covers > ocamlopt/native code. Don't you think bytecode should have some > endeavour to match or better some other language too (Java seems best > case to me in this scenario). > > About the only thing the shootout proves is that ocaml bytecode has > very good memory use compared to Java. This is not at all surprising: you are comparing two very different things. OCaml has a pure bytecode interpreter, while Java is a mix of interpreter and run-time compiler (the famous "JIT"). Microsoft's CLR is even more extreme, as all execution goes through the JIT. Their only common point is that they take bytecode as input, but they run it very differently. For a pure bytecode interpreter OCaml is pretty fast (faster than caml-light, which was already very fast), but it cannot compete with a compiler. There is also an experimental JIT runtime for OCaml (ocamljitrun), but it suffers from the difference in the bytecode design: OCaml bytecode is designed to run on a pure bytecode interpreter, so it drops all type and control flow information (which Java bytecode keeps), as it would not be useful for such an interpreter. The advantage is compactness, and good memory use. This also means that there is very little the JIT will be able to optimize. Nonetheless ocamljitrun is about twice as fast as ocamlrun, just because modern processors are very much geared towards compilers. So your question could be expressed as: is there any plan for a more expressive bytecode, that would allow JIT optimizations. The answer is that I'm not aware of any. A connected topic may be the language F#: a cousin of ocaml, built on top of Microsoft's CLR, and as such benefiting from a very good JIT runtime. That's all I know. Jacques Garrigue