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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 6A63FBC57 for ; Wed, 17 Nov 2010 09:44:06 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABANsk40zB/Bd4imdsb2JhbACiQhUBAQEKCQwHDwUfwEeFSwSKWIMM X-IronPort-AV: E=Sophos;i="4.59,210,1288566000"; d="scan'208";a="87696925" Received: from smtp-msa-out01.orange.fr ([193.252.23.120]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Nov 2010 09:44:06 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf5a03.orange.fr (SMTP Server) with ESMTP id B2F0B1C003BC; Wed, 17 Nov 2010 09:44:05 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf5a03.orange.fr (SMTP Server) with ESMTP id A440F1C00426; Wed, 17 Nov 2010 09:44:05 +0100 (CET) Received: from [192.168.1.63] (APuteaux-154-1-92-54.w83-204.abo.wanadoo.fr [83.204.167.54]) by mwinf5a03.orange.fr (SMTP Server) with ESMTP id 44F151C003BC; Wed, 17 Nov 2010 09:44:05 +0100 (CET) X-ME-UUID: 20101117084405282.44F151C003BC@mwinf5a03.orange.fr X-ME-User-Auth: lexifi Message-ID: <4CE395D4.4000105@frisch.fr> Date: Wed, 17 Nov 2010 09:44:04 +0100 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Benedikt Meurer Cc: caml-list@yquem.inria.fr Subject: Native toplevel? (was: OCamlJit 2.0) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 toplevel:01 byte-code:01 prototyping:01 prototyping:01 toplevel:01 ocaml:01 dynlink:01 compiler:01 mlp:01 mlp:01 lexifi:01 compiler:01 ocamlopt:01 On 11/16/2010 03:52 PM, Benedikt Meurer wrote: > OCamlJit 2.0 was specifically designed for desktop processors and is > not really portable to anything else in its current shape, because > the target audience are people using the interactive top-level and > the byte-code interpreter for rapid prototyping/development This looks like a very interesting project! Does performance really matter that much for rapid prototyping/development? I can imagine other uses of the toplevel where performance matters more, like theorem provers embedded in the OCaml toplevel. Anyway, another option to get a more efficient interactive top-level is to turn to native code. There is actually already a native top-level in the distribution, even though it is undocumented and unmaintained. You can build it with the "make ocamlnat" target. The implementation is based on the same approach as native dynlink. The toplevel embeds the native compiler; for each phrase, the toplevel produces assembly code, calls the assembler and the linker to produce a dynamic/shared library, and then dynamically load and execute the resulting code. This gives some latency, but it's not so bad in practice, and you get the full speed of native code. A further step to improve this native toplevel is to avoid the call to the external assembler and linker. To do that, one basically needs to replace the assembly code emitters (emit.mlp/emit_nt.mlp) with native code emitters and do the relocation/dynamic loading by hand, which is quite easy. As it turns out, LexiFi uses on a daily basis such direct binary code emitters for x86/amd64 on Windows, and that would be easy to port to other x86/amd64 platforms. The x86 version was developed internally, and the amd64 version was done by Fabrice Le Fessant. There is also some code to wrap the binary code into COFF objects (and flexdll has a stand-alone mode to produce .cmxs files without an external linker), but that would be useless for a native toplevel. The goal was to have a compiler which can be more easily embedded in our applications and deployed to our customers, without depending on any external tool. If you Benedikt, or someone else, is willing to work on a native top-level without the need to call an external assembler/linker, we are ready to extract the binary code emitters from our code base and share them with the community (with an open-source license to be determined). This requires some packaging work on our side, so we're going to do it only if there is interest in the project. (Another nice side project, for having a good native toplevel, would be to extend ocamlopt with some control over the trade-off between speed of code generation, and the performance of the generated code. One way to do it is to force the interference graph to remain not too big, by spilling early, in order to avoid quadratic behavior in the register allocator.) -- Alain