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 33B367EE49 for ; Mon, 16 Sep 2013 21:09:34 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.212.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.212.43 as permitted sender) identity=mailfrom; client-ip=209.85.212.43; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-vb0-f43.google.com) identity=helo; client-ip=209.85.212.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-vb0-f43.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcBABxXN1LRVdQrm2dsb2JhbABahBHBAIEYCBYOAQEBAQEGCwsJFCiCJQEBBAFAARsdAQMBCwYFBAcNLiEBAREBBQEcBhMIh2gBAwkGnDeMUYMHhC0KGScNZIhPAQUMjHmCbgeEHgOWEoFpjEGDShgphGgg X-IPAS-Result: ApcBABxXN1LRVdQrm2dsb2JhbABahBHBAIEYCBYOAQEBAQEGCwsJFCiCJQEBBAFAARsdAQMBCwYFBAcNLiEBAREBBQEcBhMIh2gBAwkGnDeMUYMHhC0KGScNZIhPAQUMjHmCbgeEHgOWEoFpjEGDShgphGgg X-IronPort-AV: E=Sophos;i="4.90,917,1371074400"; d="scan'208";a="27049293" Received: from mail-vb0-f43.google.com ([209.85.212.43]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Sep 2013 21:09:33 +0200 Received: by mail-vb0-f43.google.com with SMTP id h11so3240581vbh.16 for ; Mon, 16 Sep 2013 12:09:32 -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=9uIoVDtjDtxcJa4yvlPMh7j0zNX7mDJiLDj1NpJz2QU=; b=x6ABa48q4x/kXGlmFj1Ki6gc2Q9rqct86CUBmxc79rgcxpsOrru6+22/ZVPbzErIjb Fl1Jyim0vqcL3sbKAv2WG1xu3878OyiE5dh32FVSD+tvD7DQ5+eE2mgfJAeXtO3kLlP+ 0H+GkKJzoR+zaRIa4pkA6UePmiFTuScVA+/Tr9f8+j65CECaIheUiSnB2pxAJXyqc5XR ZQHMxPcNvPucVRpbGWnIJjbMqHVnllKKTjjWeUL7DM7ZGIXvQ8MfuXQ88+JtpG0G5XHB joZT6as/3X3SU0LCv02L7JNLytECRWapCNFES1pjLtkt6qkIbd+5AdmmWt/fV3UKf1ll 4GAA== X-Received: by 10.58.100.144 with SMTP id ey16mr2188573veb.25.1379358572460; Mon, 16 Sep 2013 12:09:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.70 with HTTP; Mon, 16 Sep 2013 12:09:12 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Mon, 16 Sep 2013 15:09:12 -0400 Message-ID: To: Markus Mottl Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=089e012946babac1bf04e684f119 Subject: Re: [Caml-list] Expanding the Float Array tag --089e012946babac1bf04e684f119 Content-Type: text/plain; charset=ISO-8859-1 That's a good point. Another relatively easy optimization would be to use a bit from the header on 64-bit platforms (32-bit platforms have no available bits) to indicate another form of extension, whereby an extra word is used as a bitmap to indicate which words are floats. Haskell uses a similar trick to indicate which words are pointers on the stack. This would remove the indirection of floats in the majority of cases, except of course in the stack itself. This shouldn't have an impact on marshaling. BTW bits in the 64-bit header should probably have been marked as reserved rather than making the wo_size field impossibly large. Yotam On Mon, Sep 16, 2013 at 1:14 PM, Markus Mottl wrote: > On Mon, Sep 16, 2013 at 12:49 PM, Yotam Barnoy > wrote: > > 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. > > Here is a problem: If you marshal a float array on a 64-bit platform, > how is the 32-bit platform supposed to know about the "logical" and > "physical" size of the array? On 64-bit platforms where everything is > the same size the distinction wouldn't matter, of course, but on > 32-bit it does. The header word can only provide one size (but tag > distinctions). > --089e012946babac1bf04e684f119 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's a good point.

Anoth= er relatively easy optimization would be to use a bit from the header on 64= -bit platforms (32-bit platforms have no available bits) to indicate anothe= r form of extension, whereby an extra word is used as a bitmap to indicate = which words are floats. Haskell uses a similar trick to indicate which word= s are pointers on the stack. This would remove the indirection of floats in= the majority of cases, except of course in the stack itself.=A0 This shoul= dn't have an impact on marshaling.

BTW bits in the 64-bit header should probably have been marked as= reserved rather than making the wo_size field impossibly large.

Yotam


On Mon, Sep 16, 2013 at 1:14 PM, Markus Mottl <markus.mottl@gmail.com> wrote:
On Mon, Sep 16, 2013 at 12:49 PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> 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 fo= und so far
> is that polymorphic <, <=3D, > and >=3D would not work. Ho= wever, these operators
> should not be allowed on a vector anyway since there is no natural ord= ering
> scheme for vectors. If there are other issues, please let me know.

Here is a problem: If you marshal a float array on a 64-bit platform,=
how is the 32-bit platform supposed to know about the "logical" a= nd
"physical" size of the array? =A0On 64-bit platforms where everyt= hing is
the same size the distinction wouldn't matter, of course, but on
32-bit it does. =A0The header word can only provide one size (but tag
distinctions).
--089e012946babac1bf04e684f119--