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 3154A7EE49 for ; Tue, 17 Sep 2013 02:31:36 +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.220.173; 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.220.173 as permitted sender) identity=mailfrom; client-ip=209.85.220.173; 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-vc0-f173.google.com) identity=helo; client-ip=209.85.220.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-vc0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoCAFuiN1LRVdytlGdsb2JhbABbhBHBBoEYCBYOAQEBAQcLCwkSKoIlAQEEAUABGx0BAwELBgULDS4hAQERAQUBHAYTh3ABAwkGnE2MUYMHhC0KGScNZIhRAQUMjG+CbAeEHgOWEoFpjEGDShgphGgg X-IPAS-Result: AnoCAFuiN1LRVdytlGdsb2JhbABbhBHBBoEYCBYOAQEBAQcLCwkSKoIlAQEEAUABGx0BAwELBgULDS4hAQERAQUBHAYTh3ABAwkGnE2MUYMHhC0KGScNZIhRAQUMjG+CbAeEHgOWEoFpjEGDShgphGgg X-IronPort-AV: E=Sophos;i="4.90,919,1371074400"; d="scan'208";a="27064289" Received: from mail-vc0-f173.google.com ([209.85.220.173]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Sep 2013 02:31:35 +0200 Received: by mail-vc0-f173.google.com with SMTP id if17so2935981vcb.4 for ; Mon, 16 Sep 2013 17:31:34 -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=cX0re2UT926L2X/+QyCFq/gup86mP9Wjmpx1dng4IDQ=; b=GsxALlZNkHtk6OpfX85b6VMxmtW/+xZHoZsi3n49y8Yvbc0HSp3nh6Fu91BB0alALq 2iULf4s4EqmPCcKZ6/PsRwC8nU24kEzea411HrAIaOg+NKfWaRJYaovYvn4jRj4BwirE WidPq2MYWwm/Hl00mnnt0hmVkM10PId5v1IyNtORnJbH2xccCUTIpaYaJ1PzpoiJIMz0 6JwYKZfzmJ2W9v7dSyM4IvHKHbc0P9hCgfE/c+yjoR3VYtwuLg3G9P0XheaepMGQjKx2 oiCb87BMrC03gG578d1TSXfSArGisN/y/18AjI+wy9efDz776YggkUmdpjgYzVQvrdTs RHAA== X-Received: by 10.52.120.78 with SMTP id la14mr25490192vdb.9.1379377893931; Mon, 16 Sep 2013 17:31:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.70 with HTTP; Mon, 16 Sep 2013 17:31:13 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Mon, 16 Sep 2013 20:31:13 -0400 Message-ID: To: Markus Mottl Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=e89a8f23463561008404e6897197 Subject: Re: [Caml-list] Expanding the Float Array tag --e89a8f23463561008404e6897197 Content-Type: text/plain; charset=ISO-8859-1 At the same time, there's something to be said for not having this functionality in the runtime system at all. Why should marshaling even be done at a layer that lacks proper type information? What if we wanted to make data representation more efficient by packing booleans together under some circumstances? The marshal code wouldn't be able to handle it because it has no type information. I would much rather see a transition to Core's bin_prot ie. generated, typed code and forget about the marshal module altogether. Yotam On Mon, Sep 16, 2013 at 3:09 PM, Yotam Barnoy wrote: > 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). >> > --e89a8f23463561008404e6897197 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
At the same time, there's something to be said fo= r not having this functionality in the runtime system at all. Why should ma= rshaling even be done at a layer that lacks proper type information? What i= f we wanted to make data representation more efficient by packing booleans = together under some circumstances? The marshal code wouldn't be able to= handle it because it has no type information. I would much rather see a tr= ansition to Core's bin_prot ie. generated, typed code and forget about = the marshal module altogether.

Yotam


On Mon, Sep 16, 2013 at 3:09 PM, Yotam Barnoy <yotambarnoy= @gmail.com> wrote:
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 ava= ilable bits) to indicate another form of extension, whereby an extra word i= s used as a bitmap to indicate which words are floats. Haskell uses a simil= ar trick to indicate which words are pointers on the stack. This would remo= ve the indirection of floats in the majority of cases, except of course in = the stack itself.=A0 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 <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).

--e89a8f23463561008404e6897197--