From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 268817EE49 for ; Wed, 18 Sep 2013 17:10:23 +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.178; 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.178 as permitted sender) identity=mailfrom; client-ip=209.85.128.178; 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-f178.google.com) identity=helo; client-ip=209.85.128.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-ve0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukCAJ3BOVLRVYCylGdsb2JhbABZgz9SwSiBEwgWDgEBAQEHCxQSKoIlAQEEAUABFAcdAQMBCwYFCwM4IgERAQUBHAYTCYdnAQMJBgycM4xRgweEGwoZJw1kiF4BBQyPNSYHhB4Dl3uQCxgphGgg X-IPAS-Result: AukCAJ3BOVLRVYCylGdsb2JhbABZgz9SwSiBEwgWDgEBAQEHCxQSKoIlAQEEAUABFAcdAQMBCwYFCwM4IgERAQUBHAYTCYdnAQMJBgycM4xRgweEGwoZJw1kiF4BBQyPNSYHhB4Dl3uQCxgphGgg X-IronPort-AV: E=Sophos;i="4.90,929,1371074400"; d="scan'208";a="33395322" Received: from mail-ve0-f178.google.com ([209.85.128.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Sep 2013 17:10:21 +0200 Received: by mail-ve0-f178.google.com with SMTP id jw12so5828881veb.9 for ; Wed, 18 Sep 2013 08:10:21 -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=U9q6Lt6MPeXuFYnRlHWTneERnQw+ePtXT6PyWOVgaaI=; b=NjVu87kLG6AuqToxAuYOE5Q85ub0nteID6bkNXG20JMhfa8ThtUHT8U11Uv9n2/mwh 143q5I1h8pj/9QBPtxt2ESNM2kEVsV6QGg4nkIiS5SxALu7f2U0FafwX2n/hHiBlECI0 BG/yQrRqxlnN1PwVcoeLman27jyLu/CO3jba1l2cUm7AlFcnED5jvdFSBHQkuD8Dxe2h HRrpSAulj9LLLjb0htayIugg531ByqQmfO3c6d+xZnaxC38i0j9uYLWgPb3+3C0TOx40 qdd7luuYF8ky4RIpGMaUPPqCOOtOugDn21rZeYjeXYPJ/TqQu/qUKkaHfNxkZAHxNqOr /rog== X-Received: by 10.58.73.202 with SMTP id n10mr38672747vev.7.1379517021130; Wed, 18 Sep 2013 08:10:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.70 with HTTP; Wed, 18 Sep 2013 08:10:00 -0700 (PDT) In-Reply-To: <1379410360.10274.156.camel@zotac> References: <1379410360.10274.156.camel@zotac> From: Yotam Barnoy Date: Wed, 18 Sep 2013 11:10:00 -0400 Message-ID: To: Gerd Stolpmann Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=047d7bacbb5c0195b204e6a9d665 Subject: Re: [Caml-list] Expanding the Float Array tag --047d7bacbb5c0195b204e6a9d665 Content-Type: text/plain; charset=ISO-8859-1 So here is my tentative proposal: For 32-bit platforms, a specific tag will signify the extra header word. This word will have 16 bits' worth of tag. I think 65000 tags are enough, right? This isn't one of those "128KB will always be enough" kind of thing, is it? The top 16 bits can be used for other things. For example, a constructor with up to 16 words could specify using a 16-bit bitfield which of its members are floats. So a constructor with floats would automatically use the expanded header. An array of records (with no floats) could have the record size specified in 16 bits. For 64-bit platforms, the expanded 16-bit tag could reside in the same header, with one bit extra used to specify the extra header word for any given tag. With 64 bits available, this extra header can be very powerful: it could be used to specify 64 words worth of floats for constructors, or it could specify a 5-bit record size for an array together with 32 bits to specify the floats in the record. Yotam On Tue, Sep 17, 2013 at 5:32 AM, Gerd Stolpmann wrote: > Am Montag, den 16.09.2013, 11:26 -0400 schrieb Yotam Barnoy: > > 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. > > > > The only use-case I've seen so far for Double_array tags is for > > polymorphic comparison ie. we need the type information to parse > > doubles correctly. However, the only default comparison that's valid > > on an array of anything is an equality comparison, which is easily > > doable without type information. Therefore, I'm confused as to why > > this is necessary. > > You also need the Double_array tags for normal array accesses on 32 bit > platforms: If you call a polymorphic function taking an array argument, > the function doesn't know whether it is called with a float array or a > normal array. Because of this, the compiler generates a dynamic check > whether the array is float or something else. For float, every element > is 64 bits wide, but for anything else it is 32 bits only. > > You are right that a special "no-scan" tag would speed up the GC marking > phase when there are large arrays profiting from it - for all other > no-scan cases except float. > > Gerd > > > > Thanks in advance for any answers > > > > Yotam Barnoy > > > > -- > ------------------------------------------------------------ > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > My OCaml site: http://www.camlcity.org > Contact details: http://www.camlcity.org/contact.html > Company homepage: http://www.gerd-stolpmann.de > ------------------------------------------------------------ > --047d7bacbb5c0195b204e6a9d665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So here is my tentative proposal:

F= or 32-bit platforms, a specific tag will signify the extra header word. Thi= s word will have 16 bits' worth of tag. I think 65000 tags are enough, = right? This isn't one of those "128KB will always be enough" = kind of thing, is it? The top 16 bits can be used for other things. For exa= mple, a constructor with up to 16 words could specify using a 16-bit bitfie= ld which of its members are floats. So a constructor with floats would auto= matically use the expanded header. An array of records (with no floats) cou= ld have the record size specified in 16 bits.

For 64-bit platforms, the expanded 16-bit tag could reside in the same = header, with one bit extra used to specify the extra header word for any gi= ven tag. With 64 bits available, this extra header can be very powerful: it= could be used to specify 64 words worth of floats for constructors, or it = could specify a 5-bit record size for an array together with 32 bits to spe= cify the floats in the record.

Yotam


On Tue, Sep 17, 2013 at 5:32 AM, Gerd Stolpmann <info@ger= d-stolpmann.de> wrote:
Am Montag, den 16.09.2013, 11:26 -0400 schri= eb Yotam Barnoy:
> 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? T= his
> would allow optimization of all cases where no pointers are involved,<= br> > including float tuples, records with ints, bools and floats etc.
>
> The only use-case I've seen so far for Double_array tags is for
> polymorphic comparison ie. we need the type information to parse
> doubles correctly. However, the only default comparison that's val= id
> on an array of anything is an equality comparison, which is easily
> doable without type information. Therefore, I'm confused as to why=
> this is necessary.

You also need the Double_array tags for normal array accesses o= n 32 bit
platforms: If you call a polymorphic function taking an array argument,
the function doesn't know whether it is called with a float array or a<= br> normal array. Because of this, the compiler generates a dynamic check
whether the array is float or something else. For float, every element
is 64 bits wide, but for anything else it is 32 bits only.

You are right that a special "no-scan" tag would speed up the GC = marking
phase when there are large arrays profiting from it - for all other
no-scan cases except float.

Gerd
>
> Thanks in advance for any answers
>
> Yotam Barnoy
>

--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany =A0 =A0gerd@gerd-stolpmann.de
My OCaml site: =A0 =A0 =A0 =A0 =A0http://www.camlcity.org
Contact details: =A0 =A0 =A0 =A0http://www.camlcity.org/contact.html
Company homepage: =A0 =A0 =A0 http://www.gerd-stolpmann.de
------------------------------------------------------------

--047d7bacbb5c0195b204e6a9d665--