From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id A1705BC84 for ; Wed, 30 Mar 2005 16:35:06 +0200 (CEST) Received: from mail.exomi.com (mail.exomi.com [217.169.64.72]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2UEZ65N026335 for ; Wed, 30 Mar 2005 16:35:06 +0200 Received: from dsws (dsws.exomi.com [10.0.20.63]) by mail.exomi.com (Postfix) with ESMTP id F0CD35E0F; Wed, 30 Mar 2005 17:35:05 +0300 (EEST) Subject: Re: [Caml-list] 32- and 64-bit performance From: Ville-Pertti Keinonen To: Jon Harrop Cc: caml-list@yquem.inria.fr In-Reply-To: <200503301353.35474.jon@ffconsultancy.com> References: <200503300340.15874.jon@ffconsultancy.com> <424A6632.1020902@barettadeit.com> <1112173304.27770.22.camel@dsws> <200503301353.35474.jon@ffconsultancy.com> Content-Type: text/plain Date: Wed, 30 Mar 2005 17:34:19 +0300 Message-Id: <1112193260.27768.34.camel@dsws> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 424AB91A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 run-time:01 bigarrays:01 arrays:01 constructors:01 constructors:01 ...:98 wrote:01 strings:01 floats:01 floats:01 ints:01 essentially:01 variant:02 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Wed, 2005-03-30 at 13:53 +0100, Jon Harrop wrote: > This raises the question of exactly which OCaml types incur 64-bit quantities > in the run-time. My guess: Basically everything except strings and Bigarrays. > records (except those with all-float fields) They are 64-bit, but for records and arrays of floats, the representation is essentially the same as on 32-bit systems (except that the header word is bigger, of course), so you don't really lose much, plus you avoid the loss in performance due to an average of half of all floats being misaligned (which is pretty significant). > But isn't there quite a low limit on the number of constant variant type > constructors allowed? So maybe they're squeezed into something a little > smaller... I think the limitation is simply due to non-constant variant constructors, which store the tag in the header word. Constant constructors are simply ints.