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 D2CEE7EE49 for ; Fri, 20 Sep 2013 04:18:52 +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.220.182; 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.220.182 as permitted sender) identity=mailfrom; client-ip=209.85.220.182; 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-vc0-f182.google.com) identity=helo; client-ip=209.85.220.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-vc0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmICAKyvO1LRVdy2lGdsb2JhbABbhBHBMYEYCBYOAQEBAQcLCwkSKoIlAQEEAUABGx0BAwELBgUEBzsiAREBBQEcBi6HVQEDCQacBIxRgweEIQoZJw1kiQABBQyPWweEHgOXfJAMGCmEaCA X-IPAS-Result: AmICAKyvO1LRVdy2lGdsb2JhbABbhBHBMYEYCBYOAQEBAQcLCwkSKoIlAQEEAUABGx0BAwELBgUEBzsiAREBBQEcBi6HVQEDCQacBIxRgweEIQoZJw1kiQABBQyPWweEHgOXfJAMGCmEaCA X-IronPort-AV: E=Sophos;i="4.90,941,1371074400"; d="scan'208";a="33608712" Received: from mail-vc0-f182.google.com ([209.85.220.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Sep 2013 04:18:51 +0200 Received: by mail-vc0-f182.google.com with SMTP id hf12so7023573vcb.41 for ; Thu, 19 Sep 2013 19:18:50 -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=ky7N00Xlsk4y7H5T1rihmvvL0v1LYHpf+y6pYi1S5+A=; b=S6pt60M2k0hfxc4edvdfVmz9CUQJAYYH4QROUWexYc2GDzOu/o5gITrXmdHC15Ev+t LC24VYQ3lXmhf/H3kb1KyC2wyIKK6TYVNvbmSzCglWI5ECHM+3gygG4k2jDS525cyPFW nK7xW1ph530deUbKFZF7y7pXE2GZ0SipnWT3V1YZBJzDzWAiYxKwGQx7yomPQBKPxtGQ YTimXybIOS7WYohm8+XQEElEQfVax1BS7FVwEVkTH+mRJcD+I9wSfetPgZwXGKkhlf7S EkacbToDO+i2/2DGUu4L/0t/XRE/gBsRgCS43q6+oiblY6vfCM3sMkPicoMkqCLEFk01 xsDw== X-Received: by 10.220.164.70 with SMTP id d6mr3881706vcy.19.1379643530854; Thu, 19 Sep 2013 19:18:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.160.70 with HTTP; Thu, 19 Sep 2013 19:18:30 -0700 (PDT) In-Reply-To: <20130919101020.GE25801@frosties> References: <1379410360.10274.156.camel@zotac> <20130919101020.GE25801@frosties> From: Yotam Barnoy Date: Thu, 19 Sep 2013 22:18:30 -0400 Message-ID: To: Goswin von Brederlow Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=047d7b414aa492c79404e6c74a6f Subject: Re: [Caml-list] Expanding the Float Array tag --047d7b414aa492c79404e6c74a6f Content-Type: text/plain; charset=ISO-8859-1 > 1) unboxed floats > > The double_array_tag saves a lot (50%) of ram because the floats are > not individually boxed. For mixed blocks a bitfield could also allow > unboxed floats. > > Inspecting the contents of such a block would be more complex then > because, on 32bit, a is-float bit means the float is stored in 2 > fields and the inspection has to combine the current field with the > next and skip over the next field. > > You want to use a 16-bit bitfield to indicate which members are float. > This would work for record and constructors with up to 16 members. I > would modify this a bit. The lower 15 bit indicate which of the first > 15 members are float while the 16th bit indicates if all remaining > members are floats. If you declare the 16-bit value as signed and use > arithmetic shift right to iterate through the bits you get this > naturally. > > This sounds good. On 64 bit platforms, of course, you could use the second double word to indicate many more unboxed floats. And let's not forget that this impacts performance as well as memory usage. > 2) values the GC doesn't need to scan > > This would probably be far more often usefull. There are tons of > tuples and records that contain only primitive types (int, bool, unit, > ...). This is also true for a lot of variant types. So a simple > flat_tag would only cover half the cases. A flat bit would be better. > On the other hand a bitfield for values the GC doesn't have to inspect > seems pointless. Each value already has a bit for that. > Yeah. As soon as I start going down this path, I start thinking of haskell's heap solution, which is so elegant: a size field indicates how many pointers there are in the data structure, and all pointers are moved to the beginning of the structure. This allows them to have full size integers as well as unboxed floats. The cost is a less intuitive object layout. Of course, they don't have to worry about polymorphic compare or marshaling, since typeclasses cover all of these things in the form of attached dictionaries. Think of how much work they're saving the garbage collector though: they never have to read non-pointer values. If only haskell wasn't lazy :) ... BTW can anyone think of a downside to haskell's approach (other than the fact that ocaml needs to keep track of which values are floats for polymorphic reasons)? Yotam --047d7b414aa492c79404e6c74a6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


=A0
1) unboxed floats

The double_array_tag saves a lot (50%) of ram because the floats are
not individually boxed. For mixed blocks a bitfield could also allow
unboxed floats.

Inspecting the contents of such a block would be more complex then
because, on 32bit, a is-float bit means the float is stored in 2
fields and the inspection has to combine the current field with the
next and skip over the next field.

You want to use a 16-bit bitfield to indicate which members are float.
This would work for record and constructors with up to 16 members. I
would modify this a bit. The lower 15 bit indicate which of the first
15 members are float while the 16th bit indicates if all remaining
members are floats. If you declare the 16-bit value as signed and use
arithmetic shift right to iterate through the bits you get this
naturally.

This sounds good. On 64 bit platforms, of course, you= could use the second double word to indicate many more unboxed floats. And= let's not forget that this impacts performance as well as memory usage= .

=A0
2) values the GC doesn't need to scan

This would probably be far more often usefull. There are tons of
tuples and records that contain only primitive types (int, bool, unit,
...). This is also true for a lot of variant types. So a simple
flat_tag would only cover half the cases. A flat bit would be better.
On the other hand a bitfield for values the GC doesn't have to inspect<= br> seems pointless. Each value already has a bit for that.

Yeah. As soon as I start going down this path, I start thi= nking of haskell's heap solution, which is so elegant: a size field ind= icates how many pointers there are in the data structure, and all pointers = are moved to the beginning of the structure. This allows them to have full = size integers as well as unboxed floats. The cost is a less intuitive objec= t layout. Of course, they don't have to worry about polymorphic compare= or marshaling, since typeclasses cover all of these things in the form of = attached dictionaries.

Think of how much work they're saving the garbage collector though:= they never have to read non-pointer values. If only haskell wasn't laz= y=A0 :) ... BTW can anyone think of a downside to haskell's approach (o= ther than the fact that ocaml needs to keep track of which values are float= s for polymorphic reasons)?
=A0
Yotam

--047d7b414aa492c79404e6c74a6f--