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.6 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 29A16BBAF for ; Mon, 23 Mar 2009 20:32:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwBAFOAx0nUnwcjjWdsb2JhbACCH5NSAgEBCQkKCQ8GRbtmgmABgR0G X-IronPort-AV: E=Sophos;i="4.38,409,1233529200"; d="scan'208";a="26158767" Received: from relay.ptn-ipout01.plus.net ([212.159.7.35]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Mar 2009 20:32:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQHAFOAx0nUnw6S/2dsb2JhbACCH5RVu2aCYAGBHQY Received: from ptb-relay02.plus.net ([212.159.14.146]) by relay.ptn-ipout01.plus.net with ESMTP; 23 Mar 2009 19:32:06 +0000 Received: from [87.115.34.174] (helo=leper.local) by ptb-relay02.plus.net with esmtp (Exim) id 1LlpsU-0007ii-1M for caml-list@yquem.inria.fr; Mon, 23 Mar 2009 19:32:06 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Google summer of Code proposal Date: Mon, 23 Mar 2009 19:38:04 +0000 User-Agent: KMail/1.9.9 References: <200903211439.47107.cdome@bk.ru> <49C79A54.5020406@inria.fr> In-Reply-To: <49C79A54.5020406@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903231938.04825.jon@ffconsultancy.com> X-Plusnet-Relay: 054b3cfd15b9e411812f4010472e34e6 X-Spam: no; 0.00; ocaml:01 compiler:01 compiler:01 run-time:01 ffi:01 camlp:01 ocaml:01 run-time:01 ocaml's:01 type-based:01 ffi:01 ocaml's:01 pointer:01 bytecode:01 trivial:01 On Monday 23 March 2009 14:19:00 Xavier Leroy wrote: > 3- A language implementation like OCaml breaks down in four big parts: > 1- Front-end compiler > 2- Back-end compiler and code emitter > 3- Run-time system > 4- OS interface > Of these four, the back-end is not the biggest part nor the most > complicated part. LLVM gives you part 2, but you still need to > consider the other 3 parts. Saying "I'll do 1, 3 and 4 from scratch", > Harrop-style, means a 5-year project. On the contrary, my "style" was to provide the features that I value (multicore & FFI) in a usable form (stop-the-world) with the shortest possible development time (i.e. <<6 months to create something useful). Specifically: 1- Front-end compiler: use camlp4 to provide an embedded DSL for high-performance parallel numerics and/or reuse front-ends from existing compilers like OCaml, PolyML, MosML, NekoML to build completely new language implementations. 2- Back-end compiler and code emitter: reuse LLVM. 3- Run-time system: write the simplest possible precise GC and use stop-the-world to apply it to threads that may then run in parallel. 4- OS interface: make it as easy as possible to call C directly. HLVM had solved (2), (3) and (4) after only 3 months of part-time work. I vindicated my style! > 7- To finish, I'll preventively deflect some likely reactions by Jon > Harrop: > > "But you'll be tied to OCaml's data representation strategy!" > Right, but 1- implementing you own data representation strategy is > a lot of work, especially if it is type-based, and Actually I found that easy, not least because I wanted a user-friendly FFI so I just used C's data representation whenever possible. > 2- OCaml's strategy is close to optimal for symbolic computing. Is MLton not several times faster than OCaml for symbolic computing? > "But LLVM assembly is typed, so you must have types!" > Just use int32 or int64 as your universal type and cast to > appropriate pointer types in loads or stores. That is entirely possible and could be useful as an incremental improvement to OCaml's existing bytecode interpreter but it is not a step toward my goals. > "But your code will be tainted by OCaml's evil license!" > It is trivial to make ocamlopt dump Cmm code in a file or pipe. > (The -dcmm debug option already does this.) Then, you can have a > separate, untainted program that reads the Cmm code and transforms it. Again, that is another technically-feasible step away from my goals because OCaml's CMM has already been mangled for its data representation (e.g. 31-bit ints, boxed floats). > "But shadow stacks are the only way to go for GC interface!" > No, it's probably the worst approach performance-wise; even a > conservative GC should work better. Building a state-of-the-art optimized concurrent GC Leroy-style means an infinity-year project. =:-p Seriously though, I think it is essential to get a first working version of a GC that permits parallel threads. HLVM will be useful to a lot of people long before its GC gets optimized. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e