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 920047EC6E for ; Sat, 18 Jan 2014 02:35:50 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=pra; client-ip=84.93.230.244; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=mailfrom; client-ip=84.93.230.244; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@avasout03.plus.net) identity=helo; client-ip=84.93.230.244; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="postmaster@avasout03.plus.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucCADfa2VJUXeb0lWdsb2JhbABZg0OqEJFsgQwWDgEBAQEHDQkJEiqCJQEBAQMBCAIdLhkLBQcBAwIJDgMEAQEBJwcZIwoJCAIEARIJAgWHbQwJxAoXjlkmBwaCKYIJBIkPhhaeQA X-IPAS-Result: AucCADfa2VJUXeb0lWdsb2JhbABZg0OqEJFsgQwWDgEBAQEHDQkJEiqCJQEBAQMBCAIdLhkLBQcBAwIJDgMEAQEBJwcZIwoJCAIEARIJAgWHbQwJxAoXjlkmBwaCKYIJBIkPhhaeQA X-IronPort-AV: E=Sophos;i="4.95,677,1384297200"; d="scan'208";a="53790105" Received: from avasout03.plus.net ([84.93.230.244]) by mail2-smtp-roc.national.inria.fr with ESMTP; 18 Jan 2014 02:35:49 +0100 Received: from XPS ([91.125.229.6]) by avasout03 with smtp id FDbn1n00808vflX01DbpnS; Sat, 18 Jan 2014 01:35:49 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=VqIaXYGn c=1 sm=1 tr=0 a=YNNwqyIk8JSiwARLj6s6Lw==:117 a=YNNwqyIk8JSiwARLj6s6Lw==:17 a=0Bzu9jTXAAAA:8 a=XCxr5DcLagoA:10 a=Xub9RBUEA-sA:10 a=Kvk-SOs2Z7YA:10 a=8nJEP1OIZ-IA:10 a=r2vSxAw-AAAA:8 a=BR64nyZ84HQA:10 a=eh8eaQhiAAAA:8 a=ZzUJ585tAAAA:8 a=KX4s39I-nAck8rB8OUMA:9 a=wPNLvfGTeEIA:10 a=zPFvLC8Hz9YA:10 a=vocDLVfNm_QA:10 X-AUTH: jdh302:2500 Reply-To: From: "Jon Harrop" To: "'Gerd Stolpmann'" , "'Simon Cruanes'" Cc: "'Gabriel Scherer'" , "'David House'" , "'Julien Blond'" , "'Damien Guichard'" , "'Caml Mailing List'" References: <523666417617602473@orange.fr> <20140117092229.GI11251@emmental.inria.fr> <1389981421.2999.63.camel@e130> In-Reply-To: <1389981421.2999.63.camel@e130> Date: Sat, 18 Jan 2014 01:35:50 -0000 Organization: Flying Frog Consultancy Ltd. Message-ID: <02dd01cf13ed$9f391950$ddab4bf0$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGVMmux3oWA9/jUB8pCNQhCpLzZbAKDrxa3AcKC54YDCwEIUAFzEJTlAhtapUQC8/wwbZqOzaCA Content-Language: en-gb Subject: RE: [Caml-list] How much optimized is the 'a option type ? Gerd wrote: > 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. FWIW, the largest benefit of value types is in improving the topology of the heap for long-lived values rather than for stack-allocating short-lived values. For example, value types facilitate much more efficient generic hash tables. Cheers, Jon. -----Original Message----- From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Gerd Stolpmann Sent: 17 January 2014 17:57 To: Simon Cruanes Cc: Gabriel Scherer; David House; Julien Blond; Damien Guichard; Caml Mailing List Subject: Re: [Caml-list] How much optimized is the 'a option type ? 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=20 > > avoid allocation in some cases, which is interesting when it is used=20 > > as a default value for example. (The nice recent blog post by Thomas=20 > > 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=20 > > idea, because I expect a fair share of the programming practice that=20 > > currently use ('a option) to move to something like (('a, > > error-description) either) later in their lifetime, and I wouldn't=20 > > want people to avoid to do that for performance concerns. > > Historically, we've rather come to see special-case representation=20 > > optimizations (eg. array of floats) as a mistake -- but on the other=20 > > 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=20 > several people tell me they often need to use this), or other cases=20 > like optional parameters (which are not going to move to Either),=20 > would be useful and future-proof. I hope the current work on=20 > optimizations will help with this kind of cases (removing useless=20 > allocations of local options, references, exceptions when no escape is possible). >=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 ------------------------------------------------------------