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 8903D7EC6E for ; Fri, 17 Jan 2014 15:09:59 +0100 (CET) Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=KQJZ=WX=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0BAJFf2FKBaB4inGdsb2JhbABZhxe5IhYOAQEBAQEIFAk8giYBAQQjVhALDhMhAgIPBUkuh2mpJJwdF5F1gUkEmCCVRg X-IPAS-Result: Ap0BAJFf2FKBaB4inGdsb2JhbABZhxe5IhYOAQEBAQEIFAk8giYBAQQjVhALDhMhAgIPBUkuh2mpJJwdF5F1gUkEmCCVRg X-IronPort-AV: E=Sophos;i="4.95,670,1384297200"; d="scan'208";a="45182904" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 17 Jan 2014 15:09:59 +0100 Received: from emmental.inria.fr (emmental.inria.fr [128.93.0.14]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 146B5140912EB; Fri, 17 Jan 2014 15:09:57 +0100 (CET) Date: Fri, 17 Jan 2014 15:09:55 +0100 From: Simon Cruanes To: Yaron Minsky Cc: Nicolas Braud-Santoni , "caml-list@inria.fr" Message-ID: <20140117140955.GJ11251@emmental.inria.fr> References: <52D9342B.30704@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FxQkOwrLuQ+yAGv2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Jan 17 15:09:57 2014 +0100 (CET)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000022, queueID=394DE140912EC X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: Re: [Caml-list] How much optimized is the 'a option type ? --FxQkOwrLuQ+yAGv2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Fri, 17 Jan 2014, Yaron Minsky a =C3=A9crit : > I also agree with Gabriel that an option-specific optimization is not > clearly the right move. >=20 > But I wonder if a more general optimization that provided the > possibility of minting "fast-path" variants. i.e., one could have an > annotation that marked a given branch of a variant as the > "no-indirection" one, i.e., the one that doesn't lead to the > allocation of an extra block: >=20 > type ('a,'b) result =3D > | Ok of 'a [@@no_indirection] > | Error of 'b >=20 > would lead to a type where [Ok x =3D=3D x]. Some cleverness is required > then for the representation of the [Error] branch. In particular, > you'd need some dynamic test you could run to see if you were using a > value that was not the fast-path one. >=20 > The thing that I don't know if there's a solution for is the nesting > problem. i.e., can you effectively distinguish: >=20 > Ok (Ok (Error x)) >=20 > from >=20 > Error x >=20 > since they would have the same physical representation. I'm not sure > if some variant of the counting trick used for options would work here > or not. But if you could get this, it would make it possible to avoid > a large number of dirty Obj.magic hacks that people need to do to > build efficient datastructures in practice. The fact that the stdlib > needs to use Obj.magic to get the necessary performance is, I think, a > sign that something important is missing from the language. I'm not > sure if this is quite it, to be clear. Maybe I'm stating the obvious, but wouldn't value types be the general solution here? Assuming the optimizer can guarantee that the option value will not outlive the current scope, the value can be allocated on the stack or in registers. That's probably fast enough for most uses, isn't it? I think rust deals with option values exactly this way. --=20 Simon --FxQkOwrLuQ+yAGv2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJS2TmzAAoJEErAHQhJqmK2HY4P/RjBA2z50WprPGBHu7lt3Ew6 CqxwHuaGO9Ow3Hg8w56Psp4IWpW0tn95EMSmsBdB7qvzSOoili59KhYjAQz9x/fZ wqP2k9OZElCO+xR6AFxHpsqMThxes2ipFtPTjEXKXvutNCM2oNIpXRIcF80zB7R0 dDSwILwBtBjLydQCWsEuqp1uHTbNW3K59TsuvqAFoCMZligCJI0f4iDIcwXFHbkc JTNKwGXqEYrzIm/7NmfXylC4SC+2figgmPZ+9tDbSiE6TpBMUTJgYWITPlFrnpI0 G9wUl1PilpI4vOgOdAqSZnsk/kZXfoThTH1LzzLftmnLwnfODUZWe/vxDAv96frF Sk1XUEwwN/raHIwj4EAXp6lNJc3Vkl+bVIyUC4K4OY1QbuiI8+iMTO6muYVXxilV J9lIs6Y2Eb1P61reKKTFZx27weQF7lC69klRQ5UYG1N2NcPrYuOauWqItU774TzW 8hO2NWxFgPDOwLht2YYwHSqwTGdltLiE54oz/rTCZWRwA4LgJXG2heQ2mhBIvJrs FrAmZRIEq8J2zzB06QHLibj3SiVYz70UEvRf5x9RJSj2rzy9tKfTsb1uSgXLiZBg fxndX2PuMbjI8Qr2x7bxFP7ywLr8KoL4t8AyUQU5FHTVH5HcNPunLUCy6fpxpZPd 0vtVm8jiwBcLfI+oMn8+ =Cb/7 -----END PGP SIGNATURE----- --FxQkOwrLuQ+yAGv2--