From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 1EC437F7B4 for ; Sat, 1 Feb 2014 16:58:19 +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.3; 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.3; 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.3; 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: Aj0CAM4Y7VLU4w8DnGdsb2JhbABZvCqFUoEIFg4BAQEBAQYNCQkUKIIlAQEEAScTPwULCxgJJQ8FDRshE4dwAQMJDMMBHysNiTMXjHOCFgeDJIEUBJY+gWuGMhKGG4hx X-IPAS-Result: Aj0CAM4Y7VLU4w8DnGdsb2JhbABZvCqFUoEIFg4BAQEBAQYNCQkUKIIlAQEEAScTPwULCxgJJQ8FDRshE4dwAQMJDMMBHysNiTMXjHOCFgeDJIEUBJY+gWuGMhKGG4hx X-IronPort-AV: E=Sophos;i="4.95,760,1384297200"; d="scan'208";a="56431187" Received: from mout.web.de ([212.227.15.3]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Feb 2014 16:58:18 +0100 Received: from frosties.localnet ([37.49.32.119]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0MBTXi-1W0Jps1pYc-00AXAV for ; Sat, 01 Feb 2014 16:58:18 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1W9cxV-0000hy-6c; Sat, 01 Feb 2014 16:58:17 +0100 Date: Sat, 1 Feb 2014 16:58:17 +0100 From: Goswin von Brederlow To: Yotam Barnoy Cc: Jon Harrop , Ocaml Mailing List Message-ID: <20140201155817.GF1783@frosties> References: <01c401cf1891$b1fb1360$15f13a20$@ffconsultancy.com> <026101cf18dd$756c13d0$60443b70$@ffconsultancy.com> <030501cf1925$45380fa0$cfa82ee0$@ffconsultancy.com> <20140127152944.GA29326@frosties> <02c001cf1ccc$b635a9b0$22a0fd10$@ffconsultancy.com> 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:23Wv5JtJle2i3Ri4lK9IMKXcEuXgMOBE0jQ4tYrJb//8D4/yIGh hf6jRAohMlmHxGxxJGHeSWyRi2IuRYX9GaZgnYwUtzvhD7Kgcdi1hs0QyiLCbfoBnP3PwIS PjXjnMI/jpZq6zNF6NZqUhCU88wZbdtNWVfB1kcVuw4PubDQUtD6VfdjwZXdp+9hO8xaVdN Nf6J904edPXWSVjBEX7Sw== Subject: Re: [Caml-list] How much optimized is the 'a option type ? On Thu, Jan 30, 2014 at 01:43:59PM -0500, Yotam Barnoy wrote: > BTW there's a compromise with unboxing that also has benefits, which is > embedding. An [@embed] annotation could turn an array into an embedding > array, for example. This would mean that an array would have boxed members > within it ie. not accessible via pointers. The advantages are better cache > performance and that the GC could be instructed when the array is > completely flat ie. an embedded array without any pointers could be skipped > by the GC in the mark phase. It would have full polymorphism capability. > > The down side is that deallocating the array without deallocating the > embedded structure would be tricky. When deallocating, you have to check > every member to see if it should be deallocated as well. If not, you copy > the member (minor heap) or reallocate the member where it is in memory > (major heap). > > Yotam When deallocating the array you simply deallocate it all. You can't have any pointers to inside the array floating around or the GC would blow up. An array of embedded values can only be freed when nothing has access to it any more at all. And access to members can only b done as pointer to array + offset. > On Wed, Jan 29, 2014 at 11:11 AM, Yotam Barnoy wrote: > > > > > On Wed, Jan 29, 2014 at 3:32 AM, Jon Harrop wrote: > > > >> Yotam wrote: > >> > Of course, once you unbox, all parametric polymorphism is lost > >> > >> Is it? > >> > >> > > It is in haskell. In general, I don't think you can do any parametric > > polymorphism without metadata. > > > > > >> You would have to box the tuple before passing it to a polymorphic > >> function > >> with the type 'a -> 'a. However, if the function has the type 'a * 'b -> > >> 'b > >> * 'a then you could always unbox, right? let f = let t = ref 0 in function (x, y) -> t := y; (y, x) With f being unboxed you end up with a pointer to the middle of a tuple in t and the GC goes *BOOM*. Unboxed values allow only some operations. > > I don't think so. Without metadata, how do you know where one tuple member > > ends and another begins? > > > > Yotam Being unboxed you get the first member in R0 and the second in R1. MfG Goswin