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 8E66D7F706 for ; Fri, 17 Jan 2014 18:57:24 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.186 as permitted sender) identity=helo; client-ip=212.227.126.186; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUCAPNt2VLU4366lGdsb2JhbABZg0O7coEOFg4BAQEBBwsLCRIqgiUBAQEDAScuJAULC0ZXBhMJh3QMCcQDF4k3hSImB4IvggkEjw2PVQWOfw X-IPAS-Result: AuUCAPNt2VLU4366lGdsb2JhbABZg0O7coEOFg4BAQEBBwsLCRIqgiUBAQEDAScuJAULC0ZXBhMJh3QMCcQDF4k3hSImB4IvggkEjw2PVQWOfw X-IronPort-AV: E=Sophos;i="4.95,675,1384297200"; d="asc'?scan'208";a="53761525" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jan 2014 18:57:24 +0100 Received: from office1.lan.sumadev.de (dslb-088-069-142-074.pools.arcor-ip.net [88.69.142.74]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Lo5Nc-1VOZFk1c08-00foUU; Fri, 17 Jan 2014 18:57:08 +0100 Received: from [192.168.0.119] (ip-109-90-191-98.unitymediagroup.de [109.90.191.98]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 537C7C00D3; Fri, 17 Jan 2014 18:57:07 +0100 (CET) Message-ID: <1389981421.2999.63.camel@e130> From: Gerd Stolpmann To: Simon Cruanes Cc: Gabriel Scherer , David House , Julien Blond , Damien Guichard , Caml Mailing List Date: Fri, 17 Jan 2014 18:57:01 +0100 In-Reply-To: <20140117092229.GI11251@emmental.inria.fr> References: <523666417617602473@orange.fr> <20140117092229.GI11251@emmental.inria.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EVNjvm7gch//0UlrpfoE" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-Provags-ID: V02:K0:R7ArABvLa5tQjFKkUC6tZFB3Wpiy79IZ/1pkWZGuUss UWKGt30RV94FP4BiZQnAs2grlG5dzsmfBdIBrc2tFls/9LaJeh Ld4Dv3Tk1Yeyu4e33SVdQFIbGtA8rJt3CSk/hGSQdLLFKYvmza ci7+G+R3Oxji12Am8rwIKKLsZ2oYmuZ9/D2//QU1CRD+bCUhSR PD09C7o66qUl2Fo/iY2q9/sybUHrolmoK8YD2qzHG5x2tPsSmW Gjhi2E8BAKZ7eiVb+WX8I4qY2wxD6oXezlifC643rnnfKhuBGt reMAwwKxnEXYH1hXdpSPdKgRcKtQG32DcZ7Eu8QUfQkrwJqk3h uYw8DcrNU1QRFSVWLr1I= Subject: Re: [Caml-list] How much optimized is the 'a option type ? --=-EVNjvm7gch//0UlrpfoE Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Am Freitag, den 17.01.2014, 10:22 +0100 schrieb Simon Cruanes: > Le Fri, 17 Jan 2014, Gabriel Scherer a =E9crit : >=20 > > There have been recurrent discussions of optimizing `'a option` to > > avoid allocation in some cases, which is interesting when it is used > > as a default value for example. (The nice recent blog post by Thomas > > Leonard also seems to assume that `'a option` is somehow optimized.) > >=20 > > My strictly personal opinion is that I doubt this would be a good > > idea, because I expect a fair share of the programming practice that > > currently use ('a option) to move to something like (('a, > > error-description) either) later in their lifetime, and I wouldn't > > want people to avoid to do that for performance concerns. > > Historically, we've rather come to see special-case representation > > optimizations (eg. array of floats) as a mistake -- but on the other > > hand there is not much downside to record of floats. >=20 > I think optimization of some local uses of options, such as: I also think that local uses of options (and other variant types) could be candidates for optimization. Gabriel is right that the GC is good at short-living values, but that still leaves room for getting better with ultra-short-living values. My idea would be to try to delay the allocation of the block, and to use two registers, i.e. one for the tag, and one for the tagged inner value. First when the constructed value is passed to some other function, or returned, or stored inside another block, or in another register, the allocation is really done. Of course, this could also result in more work in total (especially when the compiler has no idea what the desired fast path of the algorithm is), and I guess the real problem is that you need a good heuristics to decide when to do this. But there are at least two criterions at hand: - You are not under pressure with registers - All consumers of the constructed value are inside the same function I guess this would result in a quite heavy patch for the comparatively small effect, and that's why it is not yet done. Gerd > let rec iter_stream f s =3D > match (try Some (MyStream.get s) with End_of_stream -> None) with > | None -> () > | Some (x, s') -> > f x; > iter_stream f s' >=20 > where an option is used to keep the function tail-rec (I've heard > several people tell me they often need to use this), or other cases like > optional parameters (which are not going to move to Either), would be > useful and future-proof. I hope the current work on optimizations will > help with this kind of cases (removing useless allocations of local > options, references, exceptions when no escape is possible). >=20 > > > > >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-EVNjvm7gch//0UlrpfoE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAABAgAGBQJS2W7tAAoJEAaM4b9ZLB5TMDEH/iDr0UkIItSrrWYrHmqqCpcC 14hKiEeaxsUz+EO2Xz/5qF5dlPig9iCXbb/F+CLc6efZHA+5YozVVsQBsSLkg5zj MWkk06R4aKjRhyhJt/bm96PUT8M0EWSWujbY0mvK+zVjioa3Qg5tIiyWO34aHfh6 RdJ3ah5wcLmSIF0zmyJ3t6+/TEnN0Va6HX0Fy/Yyu4hHR2rFU1NAaPu6EhL/uN6A D+qTWiZcLRjDWBgBke2tbCeymGemqwo7HVqDgjzs7Tupytdcef1GQ+WJiS39ZvHq mR29G9qFK1kg8bBvQPUfRQssVv1jcM05Uq6MHnNSAQTRfpkPQFQa3UyDojsBxBA= =01qP -----END PGP SIGNATURE----- --=-EVNjvm7gch//0UlrpfoE--