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 4ED407F7B4 for ; Sat, 1 Feb 2014 16:27:12 +0100 (CET) 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: Aj0CAMQR7VLU4w8Em2dsb2JhbABZvCqFUoEGFg4BAQEBAQYLCwkUKIIlAQEFOj8QCxgJJQ8FKCGIAwEYwn8fiWsXjjFYB4MkgRQEmCmGMhKPDIFn X-IPAS-Result: Aj0CAMQR7VLU4w8Em2dsb2JhbABZvCqFUoEGFg4BAQEBAQYLCwkUKIIlAQEFOj8QCxgJJQ8FKCGIAwEYwn8fiWsXjjFYB4MkgRQEmCmGMhKPDIFn X-IronPort-AV: E=Sophos;i="4.95,760,1384297200"; d="scan'208";a="56429320" Received: from mout.web.de ([212.227.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Feb 2014 16:27:11 +0100 Received: from frosties.localnet ([37.49.32.119]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0Lx7Mz-1VCBL41Plx-016eU1 for ; Sat, 01 Feb 2014 16:27:11 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1W9cTJ-0000cH-KJ; Sat, 01 Feb 2014 16:27:05 +0100 Date: Sat, 1 Feb 2014 16:27:05 +0100 From: Goswin von Brederlow To: Yotam Barnoy Cc: Ocaml Mailing List Message-ID: <20140201152705.GD1783@frosties> References: <20130930144842.GE8693@frosties> <20131008105246.GA15550@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:/CVAigZw8yUpAQMilcXaVPLTz/7gfWFmvxAsonE8k7CgBis8DXy ej4eSmY/n6bNv3TKKIpHxzTNcKpbUs77YdLlPH71XLtcIs6UVTCxCNUNNLYnqWLfW7foLtV wUpQbwNPV9HfrerD7YQigCSBiuoaNElXPUFNcnjxI8N9Ail6Vnn2I2/7leoAhDBN0MQb9qy uHjFj6hBYIhKHyPP9ufDg== Subject: Re: [Caml-list] Proposal: re-design of ocaml headers On Fri, Oct 11, 2013 at 11:48:52AM -0400, Yotam Barnoy wrote: > I had an idea based on (or actually copied from) something Goswin mentioned > earlier in our discussion. What if the bits can be used to indicate > embedded values? An embedded value would have a header inside the body of > the parent value, making it possible to get rid of all pointers within that > parent. This would represent a potentially large saving for the GC, as well > as reducing random jumps around memory which are very cache-stressing. Embedded values would be something like this: type p2 = { x : int; y : int; } type p3 = { xy : embedded p2; z : int; } The type p3 would still be a single block and p3.xy.x would not need an extra indirection. Right? I'm not sure this would be too usefull overall. In the above example it would be far better to have a row type like in objects. Something like type p3 = { p2 with z : int; } That would even allow using p3.x instead of p3.xy.x. It would also allow passing a p3 record to a function expecting a p2 record. With embedded types that would not be possible. An embedded type would have to be passed to other functions as pointer to the begining of the parent and offset within. Another thing is, as recently mentioned, that the compiler aparently aggregates allocations. So if you write let p2 = { x = 1; y = 2; } in let p3 = { xy = p2; z = 3; } in that results in a single allocation and p2 and p3 will be cache local. I think they will even stay next to each other during compression. Right? Embedding would get rid of the xy pointer and indirection but would it help so much? Would it be used widely? Given that embedded and not embedded types are incompatible I think this would rather be limited to stay within modules and never cross the module boundary. For example an internal hashtable would make use of it. And why have extra headers for the embedded values? Incorporate them into the main header directly and make type p3 = { xy : embedded p2; z : int; } equivalent to type p3 = { xy.x : int; xy.y: int; z : int; } A block containing 3 values. Embedding extra headers would only be usefull when embedding largish float arrays (which don't need a bit for every member) into large records. And then why not use the indifection? Given then size it probably will be negible. And for small structures use the individual bits to mark every float member independently. So overally I'm doubtfull the added complexity to recurse into embedded headers is worth it. MfG Goswin