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 70B7A7EC6E for ; Fri, 17 Jan 2014 23:53:01 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.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@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMBAFGz2VImacjlnGdsb2JhbABZhBm7J4ECHg4BAQEBAQYWCTyCJQEBAQRAAQE3AQ8LCw0uIhIBBQEcBhMbA4dnAwKbZYsThFIBBZhAEQaOfweEOIlLjlqQKhgphHc X-IPAS-Result: AuMBAFGz2VImacjlnGdsb2JhbABZhBm7J4ECHg4BAQEBAQYWCTyCJQEBAQRAAQE3AQ8LCw0uIhIBBQEcBhMbA4dnAwKbZYsThFIBBZhAEQaOfweEOIlLjlqQKhgphHc X-IronPort-AV: E=Sophos;i="4.95,676,1384297200"; d="scan'208";a="53782629" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jan 2014 23:53:00 +0100 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1W4IHb-0008IH-I5 for caml-list@inria.fr; Fri, 17 Jan 2014 17:52:59 -0500 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W4IHb-0000QQ-Ga for caml-list@inria.fr; Fri, 17 Jan 2014 17:52:59 -0500 Received: from mail-la0-f48.google.com ([209.85.215.48]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1W4IHb-00005G-BT for caml-list@inria.fr; Fri, 17 Jan 2014 17:52:59 -0500 Received: by mail-la0-f48.google.com with SMTP id er20so4064916lab.35 for ; Fri, 17 Jan 2014 14:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4DZi64b1Hdxpvz/LdVyO0+6DHxQoghn5ZVz440kkSzM=; b=dkvjQ8KL3Lmizl9KnnJiGOu8Ek7bK0d263qHDiZXtw1KZIM8eRc/NMDDZ32a+sJ9/y nxV9jBYVGj4ZjYaNbz933zObYhwpKqNZoRNMQ9/X87yumg8zZm6UmzDUzKB4Id4Tpz/x 9eKAqLPaY3QO7SkiHybZhr3TlMqO73gcfJ6Fw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4DZi64b1Hdxpvz/LdVyO0+6DHxQoghn5ZVz440kkSzM=; b=OpZb7I2nhtZbKYkWA4aCfy4j8RQXQTyk36RQLrYlf03Fkv4J72vvO7cvifGmMTrkdT dCtihCUCaupoZuNkQjYzmBpp0kymz+YD0fmvEaNFbie/zFG5hp7zs4RWwtjzhN6aGFFg crzmZDFraayRlhXxlN4yFWxzUk+FLzsK4A8R2Oo4WUiyQOThrc9GTP7tHfJPbUbyjeU1 d2fFrmjHJZs/1+SXfSok09gxxWuMUsV4x0vjQxCKUKwK2Z/FkYmcyE5uqQeDrZu3ap3L UJ2RfnvaZfrGldD7N/wlILITwmFnD0gDgXjQzNDzHBcubyzcv4gCINqx/nf3YQTOsysq ECdA== X-Gm-Message-State: ALoCoQkDiuZH9bCQx1BR2NChvkG/7PwXSNIQfHQrQyN7T9ArF9wTMzunY8Mz1GkvT/xfM1OPwVC+A9GbKH/GxEZ3VK/fTR85LFXaDYvMK1AS7igFkCAN9F+riViEIm+3jdGEVMUzX4OVLtRRqPLd0JPAm1wGIi6Cmw== X-Received: by 10.112.210.232 with SMTP id mx8mr2223999lbc.6.1389999178705; Fri, 17 Jan 2014 14:52:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.210.232 with SMTP id mx8mr2223997lbc.6.1389999178629; Fri, 17 Jan 2014 14:52:58 -0800 (PST) Received: by 10.112.5.70 with HTTP; Fri, 17 Jan 2014 14:52:58 -0800 (PST) In-Reply-To: <20140117140955.GJ11251@emmental.inria.fr> References: <52D9342B.30704@gmail.com> <20140117140955.GJ11251@emmental.inria.fr> Date: Fri, 17 Jan 2014 17:52:58 -0500 Message-ID: From: Yaron Minsky To: Simon Cruanes Cc: Nicolas Braud-Santoni , "caml-list@inria.fr" 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 ? I don't think it's enough. Quite often these values are long-lived enough that the analysis for short-lived objects would not help. Short lived allocations are considerably cheaper anyway, so the bigger win is on allocations that make it to the major heap. Representation hacking has good uses. Lazy is a fine example, where lazy values are made considerably cheaper by the fact that OCaml removes the extra level of indirection when a lazy is forced. Not all representation hacks have worked out so well, I would argue. I think there's relatively wide agreement that we'd be better off without the float hack for arrays. It complicates lots of things, including the lazy hack! y On Fri, Jan 17, 2014 at 9:09 AM, Simon Cruanes wrote: > Le Fri, 17 Jan 2014, Yaron Minsky a =E9crit : >> I also agree with Gabriel that an option-specific optimization is not >> clearly the right move. >> >> 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: >> >> type ('a,'b) result =3D >> | Ok of 'a [@@no_indirection] >> | Error of 'b >> >> 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. >> >> The thing that I don't know if there's a solution for is the nesting >> problem. i.e., can you effectively distinguish: >> >> Ok (Ok (Error x)) >> >> from >> >> Error x >> >> 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. > > > -- > Simon