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 BE4B37EE49 for ; Fri, 20 Sep 2013 08:25:11 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYCAJjpO1LU4w8ElGdsb2JhbABbwAaFP4EgFg4BAQEBBwsLCRIqgiUBAQUnEz8QCxgJJQ8FKCEuh1UBFrAqH4oij2cHgx6BAAOUH4Nchh6Ofg X-IPAS-Result: AlYCAJjpO1LU4w8ElGdsb2JhbABbwAaFP4EgFg4BAQEBBwsLCRIqgiUBAQUnEz8QCxgJJQ8FKCEuh1UBFrAqH4oij2cHgx6BAAOUH4Nchh6Ofg X-IronPort-AV: E=Sophos;i="4.90,941,1371074400"; d="scan'208";a="33626115" Received: from mout.web.de ([212.227.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 20 Sep 2013 08:25:10 +0200 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MTdS4-1VVbJW0ea8-00QVUX for ; Fri, 20 Sep 2013 08:25:10 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1VMu9N-0002Aw-Gp; Fri, 20 Sep 2013 08:25:09 +0200 Date: Fri, 20 Sep 2013 08:25:09 +0200 From: Goswin von Brederlow To: Yotam Barnoy Cc: Ocaml Mailing List Message-ID: <20130920062509.GA8160@frosties> References: <1379410360.10274.156.camel@zotac> <20130919101020.GE25801@frosties> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:yEIAKrIAeBZNgOJ5zHD+9kw/EiVHY+YKh/qVfUOBkA4Gcn/30LI aZUwMpMio5KZQOSEwAX4t/FcwoE/CTblzAQluLzQdDvQYQpXBfHJt/lj0GzCIS3MQqEZfZj wm/j7qYt6vRmVeYycSQ4hG6jBKU2gas/LGL25J/LRxaZaFsTvtvS6B6AcfEzOUkEiF60tGb ZwFOXQ7xv7SvlzSEFwFNg== Subject: Re: [Caml-list] Expanding the Float Array tag On Thu, Sep 19, 2013 at 10:18:30PM -0400, Yotam Barnoy wrote: > > 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 You could save the number of pointer, floats and other. But comparison needs to know the order in which fields are declared. If you sort pointers to the front then you need something to unsort them for every comparison, not just for polymorphic compare and floats. Also polymorphic types would have different order depending on the actual type: # let f (x, y) = x;; val f : 'a * 'b -> 'a = # f (1, (1, 1));; - : int = 1 # f ((1, 1), 1);; - : int * int = (1, 1) How would the compiler implement f? Since (1, 1) is a pointer it would be sorted to the front so both invocations of f would get the same data. You would have to include an index mapping for every field and access fields indirectly through that. That would cost memory as well as slow down every access. MfG Goswin