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--