From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 181E87EC6E for ; Fri, 17 Jan 2014 23:29:43 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.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=mail3-smtp-sop.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 (mail3-smtp-sop.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=mail3-smtp-sop.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: AuQBACeu2VImacjlnGdsb2JhbABZg0NWqEGSZoECHg4BAQEBAQYWCTyCJQEBAQRAAQEsCwEPCwsNDSEhARIBBQEKEgYTEgkDh1MDEQMCCJtdixOEUgEFkl0DCoVWEQaMa4FhMweEOIlLinSBeoFsgTGLK4NOGCmEdw X-IPAS-Result: AuQBACeu2VImacjlnGdsb2JhbABZg0NWqEGSZoECHg4BAQEBAQYWCTyCJQEBAQRAAQEsCwEPCwsNDSEhARIBBQEKEgYTEgkDh1MDEQMCCJtdixOEUgEFkl0DCoVWEQaMa4FhMweEOIlLinSBeoFsgTGLK4NOGCmEdw X-IronPort-AV: E=Sophos;i="4.95,676,1384297200"; d="scan'208";a="45232088" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jan 2014 23:29:41 +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 1W4Hv2-0006eh-0o for caml-list@inria.fr; Fri, 17 Jan 2014 17:29:40 -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 1W4Hv1-0005wx-VS for caml-list@inria.fr; Fri, 17 Jan 2014 17:29:39 -0500 Received: from mail-la0-f50.google.com ([209.85.215.50]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1W4Hv1-0007dn-OX for caml-list@inria.fr; Fri, 17 Jan 2014 17:29:39 -0500 Received: by mail-la0-f50.google.com with SMTP id ec20so4129748lab.9 for ; Fri, 17 Jan 2014 14:29:39 -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=tNNgOW52DYHhExNWxCIGgGAGbGXLfNiY8t1e73z+qJQ=; b=IvE1vwA4JKX0ZmCGa7a0G0n+ofkndQJjkl7L0Tu6B0BiKRyidArFGd7vV4cS8w++v7 //POECqW8RXND9QFHgy/Zy2QGPgLGzXP4jPkxzGnb+AM8Yv/vAKIPLZe014v1HeGhiHq 47H6RYeBUKMtw5kYAlZQtv4m84bn5Vl6RU6ms= 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=tNNgOW52DYHhExNWxCIGgGAGbGXLfNiY8t1e73z+qJQ=; b=BUZLD1X2TU3Bn2xeCAKr8vYeGizo1TNoK7GnPSUziPvyoJ/Q0RQUd5gIdOPqb4JY2S 0qFLoZ4VZvFKFdYlf8U17f87JbV49iXRTnZ0bC6wqPFleGQQv+7HhsUe9op5+GGkFNgQ DLkoNhK+ob6vr3TpTos/sJFh7ONi39Az+8MMg0HyYSOESyJsbjtfr2dt76haRNZoopJ2 EBlYkTz21igMdy2rWUENDl2wuS2arYjsV+MCkA+/uNA59PG6jSjZOTe1piwcSLI4NoCe O05YnmZIiDorn10xaotrjM1vQBiD45/3mAS7hN13/lsHa5pdYdvFOIVwyOdWcb/EfMMl AY/A== X-Gm-Message-State: ALoCoQlJfB08el0pqPrFRdf/pv+LyP/SDRAlRvoHaTXNrMIeEt9ZgI4dx4l14lj+5SmlXSziiwFQx8H1Uo68tQfZ7cf8Ev6RGy9Ow/t4JszzfH0k1wiZhgLxVaHuYVk0XoXjx6QiwR5cd6ZpcMiAoM0jukKMJUSsDA== X-Received: by 10.152.20.201 with SMTP id p9mr227056lae.69.1389997779101; Fri, 17 Jan 2014 14:29:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.20.201 with SMTP id p9mr227050lae.69.1389997779019; Fri, 17 Jan 2014 14:29:39 -0800 (PST) Received: by 10.112.5.70 with HTTP; Fri, 17 Jan 2014 14:29:38 -0800 (PST) In-Reply-To: References: <52D9342B.30704@gmail.com> Date: Fri, 17 Jan 2014 17:29:38 -0500 Message-ID: From: Yaron Minsky To: Gabriel Scherer Cc: Nicolas Braud-Santoni , "caml-list@inria.fr" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] How much optimized is the 'a option type ? I agree that representation hacking (which is what Obj.magic is all about) is something that should be done rarely, and I don't think the Queue example justifies it. There are other hacks, though, that make sense, like the hack for lazy values, which I think is totally worth it. We've had to do a number of Obj.magic hacks in Core_kernel to get it to perform adequately. I think those hacks are a reasonably good place to look for inspiration as to how to make OCaml more hospitable for those with stringent performance requirements. For what it's worth, GADTs have been a big win in this regard, by making access to existentials cheap and easy, which can avoid a lot of pointless allocation of closures in complex libraries. I'd like to see this improve yet further by allowing for existential values to be created without an extra allocated block, which the GADT approach currently requires. If you're interested, you can look at Core_stack, Flat_queue, Dequeue and Pool to see some examples where we've needed to use Obj.magic for performance reasons. y On Fri, Jan 17, 2014 at 9:24 AM, Gabriel Scherer wrote: >> 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 think this specific example needs to die. Yes, there is an Obj.magic > in the implementation of Queue, and this mistake was committed more > than a decade ago. But we could perfectly remove this use of Obj.magic > and use different implementation techniques to get equally efficient > (or better) code. But there is no reason to change code that works > well enough. > > That some Obj.magic remains in some old code is *no excuse* to use it > today or tomorrow. > > On Fri, Jan 17, 2014 at 3:02 PM, Yaron Minsky wr= ote: >> 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. >> >> y >> >> >> On Fri, Jan 17, 2014 at 8:46 AM, Nicolas Braud-Santoni >> wrote: >>> On 17/01/2014 12:23, Jonathan Kimmitt wrote: >>>> In my humble opinion the main purpose of Some _ | None is to avoid the >>>> requirement for a nil pointer in OCaml. If an external function wants = to >>>> return nil in order to indicate, for example that a certain resource i= s not >>>> available, it can return None instead and this prevents dereferencing = a nil >>>> pointer in OCaml because the None cannot be dereferenced. >>> Yes. >>> This doesn't forbid the compiler from representing 'a option values as >>> pointers. >>> Indeed, the type system already enforces that the None case is handled >>> and the representation of None and Some _ do not matter. >>> >>> That said, I agree with Gabriel Scherer : adding optimizations specific >>> to 'a option might refrain people wanting to switch to more appropriate >>> datatypes. >>> However, would is be possible to =93optimize away=94 all types of the f= orm >>> =93type 'a t =3D X of 'a | A | B | ...=94 (with at most one non-constant >>> constructor) ? >>> Would it be worth doing ? >>> >>> >>> Kind regards, >>> Nicolas >>> >> >> -- >> 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