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 972BD7EC6E for ; Fri, 17 Jan 2014 10:11:07 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.53 as permitted sender) identity=mailfrom; client-ip=209.85.214.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f53.google.com) identity=helo; client-ip=209.85.214.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f53.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsECAJFf2FLRVdY1lGdsb2JhbABZg0NWqCiSaYEHCBYOAQEBAQcLCwkSKoIlAQEBBEABGxILAQMMBgULAwoNISEBAREBBQEKEgYTEoddAQMRDZ0OjFyDCZIUChknAwpkhHIRAQUMjF+BYTMHhDgEljWBbIExiysDg0sYKYRaOw X-IPAS-Result: AsECAJFf2FLRVdY1lGdsb2JhbABZg0NWqCiSaYEHCBYOAQEBAQcLCwkSKoIlAQEBBEABGxILAQMMBgULAwoNISEBAREBBQEKEgYTEoddAQMRDZ0OjFyDCZIUChknAwpkhHIRAQUMjF+BYTMHhDgEljWBbIExiysDg0sYKYRaOw X-IronPort-AV: E=Sophos;i="4.95,670,1384297200"; d="scan'208";a="53664336" Received: from mail-bk0-f53.google.com ([209.85.214.53]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jan 2014 10:11:07 +0100 Received: by mail-bk0-f53.google.com with SMTP id na10so1545709bkb.26 for ; Fri, 17 Jan 2014 01:11:06 -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:content-transfer-encoding; bh=me4TGjsHKteNhIlk/TrYyh808k8yaCwWPyFpcDjNf3Q=; b=jUxAs4Mye9w+PNJLKQsKINmB29azSS9nRsgOFb7pja/QCeD1PEDTdwlZyw6k7LSgww URzaQEaLbrYtmsS73ufaL/q0rZuVOIzoFFaLFxcUF+Be7zm7D8+22mxcJFyAipKZs778 saOHEZ9p833HOp1A8HhBioN8J6Ul1EkK/QxToALbjJXcetbfp8aA6qW+3W3WwXK6pNdr BMD7AfzHa/Y/ZLyAWmoxlVSUlCO8b2FxhcJvjancOVLm0fBbGHPCuKTxao3IShEmtbjL uT73jlyBQE6j67fR/W+an4fyn7Z/8IZcS6MssKnQqhqTTJ03usVkp96ohuI+8y8HcCbK sCag== X-Received: by 10.205.25.6 with SMTP id rg6mr788627bkb.10.1389949866505; Fri, 17 Jan 2014 01:11:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.45.5 with HTTP; Fri, 17 Jan 2014 01:10:26 -0800 (PST) In-Reply-To: References: <523666417617602473@orange.fr> From: Gabriel Scherer Date: Fri, 17 Jan 2014 10:10:26 +0100 Message-ID: To: David House Cc: Julien Blond , Damien Guichard , Caml Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 allocat= ed > at all. Rather than there being a pointer in that field, 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 block > which in turn points at the actual thing. So compared to a C pointer, the= re > 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 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 >>> types are represented in memory, it is not that inefficient. The only t= hing >>> that makes it less efficient than a C pointer is the header block (nece= ssary >>> for the GC). An option value always takes 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 >>> >>> >> >