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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 51DE37F75D for ; Thu, 30 Jan 2014 19:44:21 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.216.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.216.180 as permitted sender) identity=mailfrom; client-ip=209.85.216.180; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qc0-f180.google.com) identity=helo; client-ip=209.85.216.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qc0-f180.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMCAJOc6lLRVdi0lGdsb2JhbABZhBu9JIEECBYOAQEBAQcLCwkSKoIlAQEBAwEnGQEbHQEDDAYFBAcNLiEBAREBBQEcBhMIh2gBAwkIn0iMXIMJkxAKGScNZIgyEQEFDIxgghYHhDgEiUmMc4FsjF6DVBgphHce X-IPAS-Result: AqMCAJOc6lLRVdi0lGdsb2JhbABZhBu9JIEECBYOAQEBAQcLCwkSKoIlAQEBAwEnGQEbHQEDDAYFBAcNLiEBAREBBQEcBhMIh2gBAwkIn0iMXIMJkxAKGScNZIgyEQEFDIxgghYHhDgEiUmMc4FsjF6DVBgphHce X-IronPort-AV: E=Sophos;i="4.95,751,1384297200"; d="scan'208";a="47168146" Received: from mail-qc0-f180.google.com ([209.85.216.180]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Jan 2014 19:44:20 +0100 Received: by mail-qc0-f180.google.com with SMTP id i17so5536008qcy.39 for ; Thu, 30 Jan 2014 10:44:19 -0800 (PST) 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=xRr8TqlCkjBx98Sn5A59wLNBtUi+d09Wr//RaY52WXc=; b=mCOHXOqP596BLu0yE9S7AXx8hgFAoC9rHMJLmp83Tv7u5rAPkM9Qpf4qMOfb1C6X6d JhVhTd/dmhBnTbwi/r05sFQvuwRkyjeK1quOwFi9bqGgrigiqy4221TyL2KhERYTWn7y RuY6bGvOpIws+O9BLPtOehL9pdlK3lW2vyygAe6OgraenAx1yZ5AORKe9XmUsl2J1hoh XYqJYXSCwTY90LW+wj6xqJGyDZUbjtsCJh2AtO8mpaYBckXobZIawXK9T3YReeYEkRMQ MvGuvK4h5XnpYeqTl0lLT6Oz75J+AyHAnqxuDzFy2+bJniHIum5oYYSD5pKMzy6maV/c b50Q== X-Received: by 10.224.88.3 with SMTP id y3mr24722036qal.80.1391107459406; Thu, 30 Jan 2014 10:44:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.106.137 with HTTP; Thu, 30 Jan 2014 10:43:59 -0800 (PST) In-Reply-To: References: <20140120101654.GI26447@frosties> <08bc01cf17b8$9263d070$b72b7150$@ffconsultancy.com> <20140123092925.GB20624@frosties> <01c401cf1891$b1fb1360$15f13a20$@ffconsultancy.com> <026101cf18dd$756c13d0$60443b70$@ffconsultancy.com> <030501cf1925$45380fa0$cfa82ee0$@ffconsultancy.com> <20140127152944.GA29326@frosties> <02c001cf1ccc$b635a9b0$22a0fd10$@ffconsultancy.com> From: Yotam Barnoy Date: Thu, 30 Jan 2014 13:43:59 -0500 Message-ID: To: Jon Harrop Cc: Goswin von Brederlow , Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c3dbbcf6632104f13471e0 Subject: Re: [Caml-list] How much optimized is the 'a option type ? --001a11c3dbbcf6632104f13471e0 Content-Type: text/plain; charset=ISO-8859-1 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 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? >> >> > I don't think so. Without metadata, how do you know where one tuple member > ends and another begins? > > Yotam > --001a11c3dbbcf6632104f13471e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
BTW there's a compromise with unboxing that also = has benefits, which is embedding. An [@embed] annotation could turn an arra= y into an embedding array, for example. This would mean that an array would= have boxed members within it ie. not accessible via pointers. The advantag= es are better cache performance and that the GC could be instructed when th= e 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 ca= pability.

The down side is that deallocating the array without deallocating the e= mbedded structure would be tricky. When deallocating, you have to check eve= ry 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 h= eap).

Yotam


On Wed, Jan 29, 2014 at 11:11 AM, Yotam Barnoy <yotambarno= y@gmail.com> wrote:

On Wed, Jan 29, 2014 at 3:= 32 AM, Jon Harrop <jon@ffconsultancy.com> 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. =A0
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 &#= 39;a * 'b -> 'b
* 'a then you could always unbox, right?


I don't think so. Without me= tadata, how do you know where one tuple member ends and another begins?

Y= otam

--001a11c3dbbcf6632104f13471e0--