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,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 824C9BBAF for ; Sat, 26 Sep 2009 19:21:25 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCANPqvUrRVllDlGdsb2JhbACCJi2FHpMRAQEBAQkLCAkTA7lThB4F X-IronPort-AV: E=Sophos;i="4.44,457,1249250400"; d="scan'208,217";a="35054406" Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by mail3-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2009 19:21:23 +0200 Received: from [69.254.201.214] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1MraxW-00026a-DU for caml-list@inria.fr; Sat, 26 Sep 2009 13:21:22 -0400 Message-Id: From: David McClain To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=Apple-Mail-1-800574344 Mime-Version: 1.0 (Apple Message framework v936) Subject: HLVM Date: Sat, 26 Sep 2009 10:21:21 -0700 X-Mailer: Apple Mail (2.936) X-ELNK-Trace: 7a0ab3eafc8cf994b22988ad1c62733440683398e744b8a4f211c2134465c054e40430acedf07db1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.254.201.214 X-Spam: no; 0.00; arrays:01 ocaml:01 arrays:01 ocaml:01 2009:98 04.:98 2009:98 04.:98 native:03 native:03 dbm:03 dbm:03 types:05 types:05 efficient:07 --Apple-Mail-1-800574344 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yes, I saw those references already. Still not enough information... What, in particular, sets HLVM apart. Surely not just the native machine types? Are you handling array references in some unusually efficient manner? Are you avoiding unnecessary copy-on-writes of large arrays by some form of whole-program analysis? I still don't have a handle on HLVM... > > http://www.ffconsultancy.com/ocaml/hlvm/ > http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html Dr. David McClain dbm@refined-audiometrics.com --Apple-Mail-1-800574344 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yes, I saw those references = already. Still not enough information...

What, in particular, = sets HLVM apart. Surely not just the native machine types?

Are = you handling array references in some unusually efficient manner? Are = you avoiding unnecessary copy-on-writes of large arrays by some form of = whole-program analysis? I still don't have a handle on = HLVM...


http://www.ffconsultancy= .com/ocaml/hlvm/

http://flyingfrogblog.blogspot.com/2009/03/performance-oc= aml-vs-hlvm-beta-04.html


= --Apple-Mail-1-800574344-- 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.2 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 3C0A8BBAF for ; Sat, 26 Sep 2009 23:40:38 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBAJcmvkrUnwdkkWdsb2JhbACCH5hjAQEBAQkLCgcTBLg+hB4F X-IronPort-AV: E=Sophos;i="4.44,457,1249250400"; d="scan'208";a="33605518" Received: from relay.pcl-ipout02.plus.net ([212.159.7.100]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Sep 2009 23:40:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GANMmvkrUnw6T/2dsb2JhbACCH9FjhB4F Received: from ptb-relay03.plus.net ([212.159.14.147]) by relay.pcl-ipout02.plus.net with ESMTP; 26 Sep 2009 22:40:37 +0100 Received: from [87.114.87.187] (helo=leper.local) by ptb-relay03.plus.net with esmtp (Exim) id 1Mrf0P-0008Nv-4D for caml-list@yquem.inria.fr; Sat, 26 Sep 2009 22:40:37 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] HLVM Date: Sat, 26 Sep 2009 22:41:02 +0100 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909262241.02908.jon@ffconsultancy.com> X-Plusnet-Relay: fb311ff66d58a393c74bb200e71a30c4 X-Spam: no; 0.00; compilation:01 polymorphism:01 run-time:01 ocaml:01 integers:01 arrays:01 ocaml:01 allocates:01 ocaml's:01 pointer:01 pointers:01 trivial:01 ffi:01 stubs:01 hand-written:01 On Saturday 26 September 2009 18:21:21 David McClain wrote: > What, in particular, sets HLVM apart. Surely not just the native > machine types? JIT compilation opens up several hugely-productive optimizations: 1. Polymorphism no longer persists to run-time so there is no need for a uniform representation. Whereas OCaml tags integers and boxes floats and tuples with a couple of hacks for special cases like all-float-records and float arrays, HLVM never boxes any of them (including 32-bit ints, 64-bit floats and complex numbers). Moreover, this massively reduces the stress on the garbage collector. For example, although OCaml has a heavily optimized GC it is already 50% slower than the current HLVM at computing a complex FFT where the complex numbers are represented by the type float * float because OCaml allocates every intermediate tuple on the minor heap. 2. The garbage collector is partially specialized with respect to user defined types. Whereas OCaml's GC blindly traverses the heap testing almost every word to see whether or not it is a pointer, HLVM's GC JIT compiles traversal code for every type it sees and that code jumps directly to the pointers in a value. 3. The code generator can target the exact machine being used so things like SSE are trivial to implement and use. For example, the integer-based Monte-Carlo test from the SciMark2 benchmark is up to 6x faster with LLVM than with OCaml. 4. You get a native code REPL for free. 5. FFI stubs are JIT compiled for you: no more hand-written C stubs! On top of that, LLVM handles aggregate values very efficiently so HLVM lets you use them for tuples. That gives you value types (a feature that OCaml lacks, which can dramatically improve performance and interoperability) that work with tail calls (structs break tail calls on the CLR). > Are you handling array references in some unusually efficient manner? Not really. The main oddity is that references in HLVM are currently 3 word structs: one pointer to the run-time type, one word of metadata (e.g. array length) and a one word pointer that points to the real data (or NULL). That has three main advantages: 1. You can pass arrays of value types to and from C easily and efficiently. 2. You have a typed "null" pointer. So empty options, lists and arrays are represented efficiently as an unboxed value (unlike F# where empty lists and arrays are inefficient heap-allocated values) yet they can still be pretty printed correctly (which OCaml cannot even handle and F# gets wrong on optimized types like options which use the CLR's typeless null). 3. You can get to the run-time type directly with a single indirection rather than loading the value and then the run-time types from its header (two indirections). > Are you avoiding unnecessary copy-on-writes of large arrays by some > form of whole-program analysis? No. HLVM does not yet do any program analysis at all. It is currently only trying to map ML-style code to assembler (via LLVM IR) differently in order to obtain a different performance profile. Specifically, the performance profile I would like. I am not a fan of non-trivial larger scale analysis and optimization because it renders performance unpredictable. Predictable performance is one of the (many) nice aspects of OCaml that I would like to keep. > I still don't have a handle on HLVM... HLVM is an experiment to see what a next-generation implementation of a language like OCaml might look like, addressing all of OCaml's major shortcomings (interoperability, parallelism and some performance issues). My preliminary results proved that there is indeed a lot to be gained by doing this but more work is required to give HLVM all of the basic features. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e 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=2.9 required=5.0 tests=AWL,DNS_FROM_RFC_POST, HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 3286FBC37 for ; Sun, 27 Sep 2009 19:07:16 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwJAAs5v0rRVdvfkGdsb2JhbACCIzCPEod6ZD8BAQEBCQkMBxMDqSKOAgEDAgWEGQWJCw X-IronPort-AV: E=Sophos;i="4.44,461,1249250400"; d="scan'208";a="47381555" Received: from mail-ew0-f223.google.com ([209.85.219.223]) by mail4-smtp-sop.national.inria.fr with ESMTP; 27 Sep 2009 19:07:15 +0200 Received: by ewy23 with SMTP id 23so3734293ewy.26 for ; Sun, 27 Sep 2009 10:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=E9UnDhyONTO4PP17MP4eg5TfIuFlAWkuQlTLUwot9Co=; b=f2QMsmff1mZnkJOQmmc9O1xZj1uvP7CZyWZu3ZsHSH78OD7Y6du4fb6LNpXYqdohpn MVRxrk3KaaLrdgvBs1qQci5MLjzaAYGdUi4O5vgfcoYi1e+Zgg7hGIo9cVWsYs8h/SIG 1tT/aVq41s45EFubIa/pirBvmMloEBVhVLNww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=JqW/pvQWAkbaEZj88LtQYprq3pD9JOEdXxnbtJEpup4Hls2wlnwMUi7Py/gJyYuR5O fR2BfZatj7iXC2HBOSorKVfXMTFNBq2T8m1dapnnvvAuTD8sfqwyjKvMS548gYulBG8E Y4FBE/UlJJUd/5GjJGy0T5R0A38/X6JN09GM4= MIME-Version: 1.0 Sender: alpmestan@gmail.com Received: by 10.216.49.80 with SMTP id w58mr625742web.75.1254071234960; Sun, 27 Sep 2009 10:07:14 -0700 (PDT) In-Reply-To: <3A5DD7BA-C2C1-4775-9566-70EE25AE74B9@refined-audiometrics.com> References: <3A5DD7BA-C2C1-4775-9566-70EE25AE74B9@refined-audiometrics.com> Date: Sun, 27 Sep 2009 19:07:14 +0200 X-Google-Sender-Auth: 987be05729d9a7ef Message-ID: Subject: Re: [Caml-list] HLVM From: Alp Mestan To: David McClain Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001485f6ce6a7b9c4c04749236ce X-Spam: no; 0.00; ocaml:01 compiler:01 ocaml's:01 compiler:01 ocaml:01 ocaml's:01 2009:98 blog:98 2009:98 blog:98 wrote:01 wrote:01 caml-list:01 dbm:03 dbm:03 --001485f6ce6a7b9c4c04749236ce Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 27, 2009 at 6:57 PM, David McClain wrote: > And forgive me for asking what may seem a question with an obvious > answer... but now don't you also have to change the OCaml compiler back end > to target the HLVM? > The current "example" provided with HLVM is a very minimal ML-style language implementation. However, there was a Jane Street Summer Project proposal to port OCaml's current compiler to HLVM/LLVM. It hasn't been accepted. But if HLVM gets more complete and enhanced, yeah, it would require porting the compiler to target HLVM/LLVM. Regards. -- Alp Mestan http://blog.mestan.fr/ http://alp.developpez.com/ --001485f6ce6a7b9c4c04749236ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Sep 27, 2009 at 6:57 PM, David McClain <= span dir=3D"ltr"><dbm@re= fined-audiometrics.com> wrote:
And forgive me for asking what may seem a question with an obvious answer..= . but now don't you also have to change the OCaml compiler back end to = target the HLVM?

The current "example" p= rovided with HLVM is a very minimal ML-style language implementation. Howev= er, there was a Jane Street Summer Project proposal to port OCaml's cur= rent compiler to HLVM/LLVM. It hasn't been accepted.

But if HLVM gets more complete and enhanced, yeah, it would= require porting the compiler to target HLVM/LLVM.

Regards.

-= -
Alp Mestan
http://blog.mestan.f= r/
http://alp.developpez.com/
--001485f6ce6a7b9c4c04749236ce-- 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.2 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id F3BE8BCA9 for ; Mon, 28 Sep 2009 00:12:27 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8CAIaAv0rUnwckjmdsb2JhbACCH5hjAQEBAQkLCAkRBrZuhB4F X-IronPort-AV: E=Sophos;i="4.44,461,1249250400"; d="scan'208";a="47390165" Received: from relay.ptn-ipout02.plus.net ([212.159.7.36]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Sep 2009 00:12:27 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAEuAv0rUnw6S/2dsb2JhbACCH9APhB4F Received: from ptb-relay02.plus.net ([212.159.14.146]) by relay.ptn-ipout02.plus.net with ESMTP; 27 Sep 2009 23:12:27 +0100 Received: from [87.114.87.187] (helo=leper.local) by ptb-relay02.plus.net with esmtp (Exim) id 1Ms1yl-0007vY-2H for caml-list@yquem.inria.fr; Sun, 27 Sep 2009 23:12:27 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] HLVM... Date: Sun, 27 Sep 2009 23:12:54 +0100 User-Agent: KMail/1.9.9 References: <2084D077-4ACC-4054-9DFF-A4B23F76BA31@refined-audiometrics.com> In-Reply-To: <2084D077-4ACC-4054-9DFF-A4B23F76BA31@refined-audiometrics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909272312.54737.jon@ffconsultancy.com> X-Plusnet-Relay: 083fe5dd7fcfcaaa55c6e3b958c42b55 X-Spam: no; 0.00; integers:01 transitions:01 2009:98 frog:98 wrote:01 caml-list:01 arithmetic:01 explicitly:02 primitive:02 native:03 overflow:03 types:05 implicitly:05 converting:05 modulo:07 On Sunday 27 September 2009 23:09:02 David McClain wrote: > ... remember too, in signal and image processing applications, > converting to raw machine integers and plowing ahead is often > counterproductive. > > Rather we need saturating arithmetic to avoid abrupt transitions on > overflow conditions, or modulo addressing. Neither of these is native > to SSM, and have to be synthesized. DSP chips on the other hand almost > always offer these variations implicitly or explicitly. Sure. That does not change the fact that unnecessarily boxing these primitive types severely degrades performance. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e 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.8 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 3A05ABC37 for ; Mon, 28 Sep 2009 11:18:32 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4EAGwcwEpQRFuwWWdsb2JhbACaeQEUFwS5E4QeBQ X-IronPort-AV: E=Sophos;i="4.44,465,1249250400"; d="scan'208";a="47417464" Received: from furbychan.cocan.org ([80.68.91.176]) by mail4-smtp-sop.national.inria.fr with ESMTP; 28 Sep 2009 11:18:31 +0200 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1MsCNJ-0002RI-VT; Mon, 28 Sep 2009 10:18:29 +0100 Date: Mon, 28 Sep 2009 10:18:29 +0100 To: David McClain Cc: caml-list@inria.fr Subject: Re: [Caml-list] HLVM... Message-ID: <20090928091829.GA9193@annexia.org> References: <2084D077-4ACC-4054-9DFF-A4B23F76BA31@refined-audiometrics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2084D077-4ACC-4054-9DFF-A4B23F76BA31@refined-audiometrics.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; integers:01 transitions:01 2009:98 wrote:01 caml-list:01 arithmetic:01 explicitly:02 native:03 overflow:03 implicitly:05 converting:05 sep:06 thread:06 thread:06 modulo:07 On Sun, Sep 27, 2009 at 03:09:02PM -0700, David McClain wrote: > ... remember too, in signal and image processing applications, > converting to raw machine integers and plowing ahead is often > counterproductive. > > Rather we need saturating arithmetic to avoid abrupt transitions on > overflow conditions, or modulo addressing. Neither of these is native > to SSM, and have to be synthesized. DSP chips on the other hand almost > always offer these variations implicitly or explicitly. Please confine messages about HLVM to one thread, and don't start a new thread for every message you post. Rich. -- Richard Jones Red Hat