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 AF15F7EC6E for ; Sat, 18 Jan 2014 02:01:07 +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: AugCAAvS2VJUXeb0lWdsb2JhbABZg0OpF3qRbIEMFg4BAQEBBw0JCRIqgiUBAQEDAQgCZAsFBwEDAgkRBAEBAQ0aBxkIGwkBCQgCBAESCwUCh18DCQwJvikDCoVWF4xrghQHBoIpggkEiQ+GFocQgx2LKwOIZQ X-IPAS-Result: AugCAAvS2VJUXeb0lWdsb2JhbABZg0OpF3qRbIEMFg4BAQEBBw0JCRIqgiUBAQEDAQgCZAsFBwEDAgkRBAEBAQ0aBxkIGwkBCQgCBAESCwUCh18DCQwJvikDCoVWF4xrghQHBoIpggkEiQ+GFocQgx2LKwOIZQ X-IronPort-AV: E=Sophos;i="4.95,677,1384297200"; d="scan'208";a="53788393" Received: from avasout03.plus.net ([84.93.230.244]) by mail2-smtp-roc.national.inria.fr with ESMTP; 18 Jan 2014 02:01:07 +0100 Received: from XPS ([91.125.229.6]) by avasout03 with smtp id FD151n00508vflX01D16pD; Sat, 18 Jan 2014 01:01:07 +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=jK3bGrtaAAAA:8 a=h6pNz4pCAAAA:8 a=pGLkceISAAAA:8 a=ZOzjf2MOAAAA:8 a=CjxXgO3LAAAA:8 a=qfDhGcRhG52P1ImcpAcA:9 a=IbFCzr71GAnKMhFE:21 a=pY-lh7i3a4Xuh1E6:21 a=wPNLvfGTeEIA:10 a=WJrl4WifqjgA:10 a=MSl-tDqOz04A:10 X-AUTH: jdh302:2500 Reply-To: From: "Jon Harrop" To: "'Gabriel Scherer'" , "'David House'" Cc: "'Julien Blond'" , "'Damien Guichard'" , "'Caml Mailing List'" References: <523666417617602473@orange.fr> In-Reply-To: Date: Sat, 18 Jan 2014 01:01:07 -0000 Organization: Flying Frog Consultancy Ltd. Message-ID: <02d401cf13e8$c5fb12a0$51f137e0$@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/jUB8pCNQhCpLzZbAKDrxa3AcKC54YDCwEIUAFzEJTlmrdGKJA= Content-Language: en-gb Subject: RE: [Caml-list] How much optimized is the 'a option type ? > The OCaml GC is very good at optimizing *short-lived* allocations I see lots of people still asserting that. I think it needs quantifying. AFAIK, OCaml's GC makes short-lived values 2-3x faster than long lived values or malloc/free but removing unnecessary short lived allocations can often make a function several times faster. So I think there is every reason to optimize away allocations even if they are short-lived. Obvious examples include optional arguments, options, tuples and complex numbers. > Hopefully in fifteen years we'll be using programming languages with well-typed strong update such as Mezzo ( http://protz.github.io/mezzo/ ), that can solve this problem without any kind of ad-hoc optimization. FWIW, I think value types and reified generics already solved this problem (and many other related problems). Cheers, Jon. -----Original Message----- From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Gabriel Scherer Sent: 17 January 2014 09:10 To: David House Cc: Julien Blond; Damien Guichard; Caml Mailing List Subject: Re: [Caml-list] How much optimized is the 'a option type ? 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.) 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. The OCaml GC is very good at optimizing *short-lived* allocations, so many idiomatic uses of option are in fact already quite fast despite the allocation. Using an `'a option array` for values that start undefined is not one of such cases. Hopefully in fifteen years we'll be using programming languages with well-typed strong update such as Mezzo ( http://protz.github.io/mezzo/ ), that can solve this problem without any kind of ad-hoc optimization. On Fri, Jan 17, 2014 at 9:40 AM, David House wrote: > Err, right, sorry. If you have None in, say, a record, that's not=20 > allocated at all. Rather than there being a pointer in that field,=20 > there is special word in that field which represents None. > > If that field is a Some, then it's a pointer to a two word allocated=20 > block which in turn points at the actual thing. So compared to a C=20 > pointer, there an extra two words and one more indirection. > > > On 17 January 2014 08:16, Julien Blond wrote: >> >> > An option value always takes two words: one for the header, and=20 >> > then either a pointer or a word that means "None". >> >> No. From the reference manual =A7 19.3.4 : >> >> type 'a option =3D None (* Val_int(0), i.e. just an integer va= lue >> =3D 1 word *) >> | Some of 'a (* block of size 1 =3D [(header =3D 1 >> word) + (1 field =3D 1 word)] =3D 2 words *) >> >> >> 2014/1/17 David House >>> >>> It behaves identically to that type. >>> >>> It is just like any other sum type. However, due to the way that sum=20 >>> types are represented in memory, it is not that inefficient. The=20 >>> only thing that makes it less efficient than a C pointer is the=20 >>> header block (necessary for the GC). An option value always takes=20 >>> two words: one for the header, and then either a pointer or a word that means "None". >>> >>> >>> On 17 January 2014 07:35, Damien Guichard wrote: >>>> >>>> Hello, >>>> >>>> Compared to the code : >>>> >>>> type 'a option =3D None | Some of 'a >>>> >>>> How do an 'a option value performs ? >>>> Any allocation saved ? >>>> Any indirection removed ? >>>> >>>> Is 'a option just like any sum type ? >>>> Or is 'a option more like an ANSI C pointer type ? >>>> >>>> Regards, >>>> >>>> Damien Guichard >>>> >>>> >>>> >>>> -- >>>> Caml-list mailing list. Subscription management and archives: >>>> https://sympa.inria.fr/sympa/arc/caml-list >>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>>> Bug reports: http://caml.inria.fr/bin/caml-bugs >>> >>> >> > -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs=3D