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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id C279F7EE49 for ; Mon, 16 Sep 2013 18:49:55 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.128.174; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.128.174 as permitted sender) identity=mailfrom; client-ip=209.85.128.174; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ve0-f174.google.com) identity=helo; client-ip=209.85.128.174; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-ve0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcBAJo1N1LRVYCum2dsb2JhbABagz9SwHyBFggWDgEBAQEBBgsLCRQogiUBAQQBQAEUBx0BAwELBgULDS4hAQERAQUBHAYTh3ABAwkGnCiMUYMHhBsKGScNZIhPAQUMjHmBHBSBPgeEHgOWEoFpjEGDShgphGgggS0 X-IPAS-Result: ApcBAJo1N1LRVYCum2dsb2JhbABagz9SwHyBFggWDgEBAQEBBgsLCRQogiUBAQQBQAEUBx0BAwELBgULDS4hAQERAQUBHAYTh3ABAwkGnCiMUYMHhBsKGScNZIhPAQUMjHmBHBSBPgeEHgOWEoFpjEGDShgphGgggS0 X-IronPort-AV: E=Sophos;i="4.90,916,1371074400"; d="scan'208";a="33095923" Received: from mail-ve0-f174.google.com ([209.85.128.174]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Sep 2013 18:49:54 +0200 Received: by mail-ve0-f174.google.com with SMTP id jy13so3222599veb.33 for ; Mon, 16 Sep 2013 09:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F8uzIpjGeNA80KmAa7xD20gCnMVvhG0M3bQuV03KQZ0=; b=QVoizketyeVr/AxFlZwq5gHVUsp3H0tBhtL/9LDKSfNroRARAER/dYXgb7TjRut2LU YkrzOI0fiUuBFGxi8+skp0yl3SxXefaQ3lAEo5f4uH2znu39rJEhcvM4OExReqBdv3ir q7mxUAHN0L+xSq1cVTQKz7cTP45oB0V+8A1B0OS3eSzo57NJjpy4fpmmO70hap+vZwEl /qI9WTvW7yhAwgU5HjaDBAQ30lZ3YYdiJQ4LBy/Hs4hoqa2/ymn9nIhiTNk9r34kR05o m3LxM2ZcwDTpIP1dw8JhdSkue6/hF78yISLFcze+3SnEHpF6lCsvczFQv/QGrLU1O6QR /XjA== X-Received: by 10.220.164.202 with SMTP id f10mr1617430vcy.25.1379350194010; Mon, 16 Sep 2013 09:49:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.70 with HTTP; Mon, 16 Sep 2013 09:49:33 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Mon, 16 Sep 2013 12:49:33 -0400 Message-ID: To: Markus Mottl Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c1e98055c25404e682fe4a Subject: Re: [Caml-list] Expanding the Float Array tag --001a11c1e98055c25404e682fe4a Content-Type: text/plain; charset=ISO-8859-1 Why do doubles need special handling though, even on a 32-bit system? My suggestion is that the Double_tag be changed to Flat_tag, meaning that all non-pointer objects can reside in this tag. The only issue I've found so far is that polymorphic <, <=, > and >= would not work. However, these operators should not be allowed on a vector anyway since there is no natural ordering scheme for vectors. If there are other issues, please let me know. I agree regarding the expansion of 246 constructors. This must have been kept for compatibility with 32 bit systems. I think what should happen in 32 bit systems is that one constructor should be reserved for having >246 constructors, in which case another word of memory could be utilized for the constructor code. In fact, you'd only need to use that extra word if the particular constructor exceeds 246. In 64 bit systems, the constructor count could easily be increased by a few bits, with the same backup mechanism for when you have more than X constructors (X being the maximum number of constructors). Regards, Yotam On Mon, Sep 16, 2013 at 12:29 PM, Markus Mottl wrote: > 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 > --001a11c1e98055c25404e682fe4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why do doubles need special handling though, even on = a 32-bit system? My suggestion is that the Double_tag be changed to Flat_ta= g, meaning that all non-pointer objects can reside in this tag. The only is= sue I've found so far is that polymorphic <, <=3D, > and >= =3D would not work. However, these operators should not be allowed on a vec= tor anyway since there is no natural ordering scheme for vectors. If there = are other issues, please let me know.

I agree regarding the expansion of 246 constructors. This must have bee= n kept for compatibility with 32 bit systems. I think what should happen in= 32 bit systems is that one constructor should be reserved for having >2= 46 constructors, in which case another word of memory could be utilized for= the constructor code. In fact, you'd only need to use that extra word = if the particular constructor exceeds 246. In 64 bit systems, the construct= or count could easily be increased by a few bits, with the same backup mech= anism for when you have more than X constructors (X being the maximum numbe= r of constructors).

Regards,
Yotam
=

On Mon, Sep 16, 2013 at 12:29 PM, Markus= Mottl <markus.mottl@gmail.com> wrote:
On Mon, Sep 16, 2013 at 11= :26 AM, Yotam Barnoy <yotambarn= oy@gmail.com> wrote:
> Having looked through some of the ocaml runtime's code, I have a q= uestion
> 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 op= timization
> of all cases where no pointers are involved, including float tuples, r= ecords
> with ints, bools and floats etc.

Floats are a little tricky, because they are always doubles (64 bits)= ,
even on 32-bit platforms. =A0This 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. =A0I think this number is too
small these days where 64-bit platforms are standard. =A0It's probably<= br> hard to change this design decision now by reducing the overly
generous maximum "wosize". =A0Some automatically generated APIs c= an
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. =A0Large arrays would benefit most from that. =A0Doing this in the compiler might break old marshaled data. =A0But if performance is
really critical, I could imagine trying that in a library with
well-hidden type representations.

Regards,
Markus

--
Markus Mottl =A0 =A0 =A0 =A0http://www.ocaml.info =A0 =A0 =A0 =A0markus.mottl@gmail.com

--001a11c1e98055c25404e682fe4a--