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 07CE47EE49 for ; Thu, 19 Sep 2013 12:10:22 +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.14; 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.14; 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.14; 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: AmgCAJzMOlLU4w8OlWdsb2JhbABbv36FP4EhFg4BAQEBBw0JCRIqgiUBAQU6TwsYCSUPBSiIJAEWr1UfihqPbhaDCIEAA5d7hh6Ofg X-IPAS-Result: AmgCAJzMOlLU4w8OlWdsb2JhbABbv36FP4EhFg4BAQEBBw0JCRIqgiUBAQU6TwsYCSUPBSiIJAEWr1UfihqPbhaDCIEAA5d7hh6Ofg X-IronPort-AV: E=Sophos;i="4.90,936,1371074400"; d="scan'208";a="33507906" Received: from mout.web.de ([212.227.15.14]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 19 Sep 2013 12:10:20 +0200 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0M7srs-1W8o3w42OO-00vSGu for ; Thu, 19 Sep 2013 12:10:21 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1VMbBk-0006xx-FC for caml-list@inria.fr; Thu, 19 Sep 2013 12:10:20 +0200 Date: Thu, 19 Sep 2013 12:10:20 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20130919101020.GE25801@frosties> References: <1379410360.10274.156.camel@zotac> 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:Df9R1OE9ka9zNPbdZw9dEGs+SC6bx7wGePrIp4SAqGUyJdtx/rm XWADxfLqCahK40213q0acIId2FkrLbK2CQamoah7v8Dzb4HXaw0RSB1aMOw9K9xMWV4L9Zo WYe2AgKs5i23aEZyFmIU55eR0Sq0lNowJdGbH0L+Rwb7E5hCfCgtlywjmjkbY3T+UYMDmd+ C6qMvn5fU+JkAZsx41ayg== Subject: Re: [Caml-list] Expanding the Float Array tag On Wed, Sep 18, 2013 at 11:10:00AM -0400, Yotam Barnoy wrote: > 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 You have 2 issues here: 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. 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. MfG Goswin