From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 28E707EE49 for ; Mon, 16 Sep 2013 18:29:27 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=209.85.212.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of markus.mottl@gmail.com designates 209.85.212.181 as permitted sender) identity=mailfrom; client-ip=209.85.212.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f181.google.com) identity=helo; client-ip=209.85.212.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wi0-f181.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAHMxN1LRVdS1m2dsb2JhbABagz9GDMB3gRYIFg4BAQEBAQYLCwkUKIIlAQEFQAEUBx0BAwwGBQsNLiEBAREBBQEcBhOHcAEDD5wzjFGDB4QYChknDWSITwEFDIx5gTCBPgeEHgOWEoFpjEGDShgphGgggS0 X-IPAS-Result: Al0BAHMxN1LRVdS1m2dsb2JhbABagz9GDMB3gRYIFg4BAQEBAQYLCwkUKIIlAQEFQAEUBx0BAwwGBQsNLiEBAREBBQEcBhOHcAEDD5wzjFGDB4QYChknDWSITwEFDIx5gTCBPgeEHgOWEoFpjEGDShgphGgggS0 X-IronPort-AV: E=Sophos;i="4.90,916,1371074400"; d="scan'208";a="27037094" Received: from mail-wi0-f181.google.com ([209.85.212.181]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Sep 2013 18:29:26 +0200 Received: by mail-wi0-f181.google.com with SMTP id ex4so3730766wid.8 for ; Mon, 16 Sep 2013 09:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zu5kwIIarH7MBNdvFCA7NS5PcgMk5bPlYi/ZLfsHCG0=; b=d5LxTKOWQXdCLHebWpCEvI402vNAXFE/Ob4bVnWCTayyusp8VqXHZ8vv+nwUR+9zMc Py6JvZr5C3e0Zi8k62QPfsvmu0xbwgHi6eO/k0ZaYSTkLZV5GOZJLboedD+06wlmO5rP /CZDJ74mXIMv45FmGvjWBnXip8K4+BbfYrOucAc1gGdHmlQ4oN0IBOIgNvthsXcnzrTn kmm8OMA6z2Ao6ttFXQRhIQ1ybzo3rtt3ZRk3ERk23k8D08F2fCF2JuJ+Cj+NZWxiheJK JaD8kddZDR+UIkWykoz54qKlpBvQLCQuJGLmn6jqRVaa8MV/f5otG5xFJCf1udkO9Uoc ohWA== MIME-Version: 1.0 X-Received: by 10.194.23.196 with SMTP id o4mr2127260wjf.62.1379348966140; Mon, 16 Sep 2013 09:29:26 -0700 (PDT) Received: by 10.194.172.4 with HTTP; Mon, 16 Sep 2013 09:29:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Sep 2013 12:29:26 -0400 Message-ID: From: Markus Mottl To: Yotam Barnoy Cc: Ocaml Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Expanding the Float Array tag On Mon, Sep 16, 2013 at 11:26 AM, Yotam Barnoy wrote: > Having looked through some of the ocaml runtime's code, I have a question > regarding the Double_array block tag. Why not use a single tag for all block > content that doesn't contain pointers instead? This would allow optimization > of all cases where no pointers are involved, including float tuples, records > with ints, bools and floats etc. Floats are a little tricky, because they are always doubles (64 bits), even on 32-bit platforms. This requires some special identification. Adding new tags by reducing the "No_scan_tag" might be a bad (and not backward compatible) approach, too: the maximum number of non-constant constructors is already pretty low at 246. I think this number is too small these days where 64-bit platforms are standard. It's probably hard to change this design decision now by reducing the overly generous maximum "wosize". Some automatically generated APIs can easily blow the current limit on non-constant constructors and require annoying, less efficient workarounds. I guess it might be possible to allocate blocks that are known to be all integers or atomic sum types by using the already available Abstract_tag. Large arrays would benefit most from that. Doing this in the compiler might break old marshaled data. But if performance is really critical, I could imagine trying that in a library with well-hidden type representations. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com