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 4CABF7EC6E for ; Fri, 17 Jan 2014 09:40:10 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dhouse@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dhouse@janestreet.com"; x-sender="dhouse@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dhouse@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="dhouse@janestreet.com"; x-sender="dhouse@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="dhouse@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: AhMCAJFf2FImacjlnGdsb2JhbABZg0NWqCiKFIhVgQceDgEBAQEBBhYJPIIlAQEBAwFAAQEsCwEECwsLDQ0hIQESAQUBChIGExKHXgMJCAMCCJ0OixOEUgEFklgDCoVWEQaMa4IQBAeEOJY5gWyBMYsrg04YKYRZ X-IPAS-Result: AhMCAJFf2FImacjlnGdsb2JhbABZg0NWqCiKFIhVgQceDgEBAQEBBhYJPIIlAQEBAwFAAQEsCwEECwsLDQ0hIQESAQUBChIGExKHXgMJCAMCCJ0OixOEUgEFklgDCoVWEQaMa4IQBAeEOJY5gWyBMYsrg04YKYRZ X-IronPort-AV: E=Sophos;i="4.95,670,1384297200"; d="scan'208";a="45132940" 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 09:40:09 +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 1W44yF-0008Ji-L4 for caml-list@inria.fr; Fri, 17 Jan 2014 03:40:07 -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 1W44yF-0001zw-Jx for caml-list@inria.fr; Fri, 17 Jan 2014 03:40:07 -0500 Received: from mail-qa0-f48.google.com ([209.85.216.48]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1W44yF-0000Oq-Gz for caml-list@inria.fr; Fri, 17 Jan 2014 03:40:07 -0500 Received: by mail-qa0-f48.google.com with SMTP id f11so3028591qae.21 for ; Fri, 17 Jan 2014 00:40:07 -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; bh=au65jRDSpLbe8TCPtH9G8Flc1+0xOsUR80rtFOdvZ+w=; b=vBfCMpfW8jGRhghP3YVDkeksQikffw7Y+QgZbnWTv+2AkjdnUVQw9lCjyQ5KArXHTR Dmy4hp13rDtH9KrC9dvbOzipT0OFY/O+ktDssrSGPZyPwMI4WLdRntLJjNHee7mnT4fI wTSEHO9WklwZeODRbmLokuhcRzBjTp9G6YDds= 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; bh=au65jRDSpLbe8TCPtH9G8Flc1+0xOsUR80rtFOdvZ+w=; b=HqhhQfuanyt0EM634PkCM5FdVIZ6SpIILSEURBvcQFZQ5/dcRi4WC3E2Dj6HNjtgfT BHE3Q7BJZ9XfSNhu1/Fs7dUZxboLvW5IMmI4PHOp2qvtt2RGU8uVCwHFSjPR49kTLc1u zTnajZWkuwrUOWoPuU7Br/UOwetXsCLG4PjjPkz3ECM11dB13cwgjFkiRMvqt3B8VRGc vsxAEHSkawFrRadro9dlU1UPHsT9vdXx6oUTrhwitq+R2T1eqs9Ts2bL7EuajzbZecUa RPD2+2NDYhx4OaRE0Ru+YfijfmVrkqCj0NNQHca1bVotw8yPW+tnWKqXqq67Vzym0gn8 azXQ== X-Gm-Message-State: ALoCoQm2Ip19o+EFy7h1xP/qVfiJWCXWOZ96B1Zzk25r8+Ca5foP95OiPypgW6OA7AyRCrlgz8sQs6mOZDIx0YgdGkg1X2KEGQTHttn+m+DZAkjgYCIwnNKlVavT92bg5vdudLMizSuqP59eGZXaYggnVgBbhOGkJg== X-Received: by 10.140.43.3 with SMTP id d3mr978262qga.70.1389948007355; Fri, 17 Jan 2014 00:40:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.43.3 with SMTP id d3mr978249qga.70.1389948007266; Fri, 17 Jan 2014 00:40:07 -0800 (PST) Received: by 10.140.89.47 with HTTP; Fri, 17 Jan 2014 00:40:07 -0800 (PST) In-Reply-To: References: <523666417617602473@orange.fr> Date: Fri, 17 Jan 2014 08:40:07 +0000 Message-ID: From: David House To: Julien Blond Cc: Damien Guichard , Caml Mailing List Content-Type: multipart/alternative; boundary=001a113a5fb63addf004f0267d53 Subject: Re: [Caml-list] How much optimized is the 'a option type ? --001a113a5fb63addf004f0267d53 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Err, right, sorry. If you have None in, say, a record, that's not allocated 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, 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 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 val= ue > =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 th= ing >> that makes it less efficient than a C pointer is the header block >> (necessary 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 >>> >> >> > --001a113a5fb63addf004f0267d53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Err, right, sorry. If you have None in, say, a record, tha= t's not allocated at all. Rather than there being a pointer in that fie= ld, 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 allocat= ed block which in turn points at the actual thing. So compared to a C point= er, there an extra two words and one more indirection.


On 17 J= anuary 2014 08:16, Julien Blond <julien.blond@gmail.com> wrote:
> An option value always takes two words: one for the heade= r, 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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (* Val_= int(0), i.e. just an integer value =3D 1 word *)
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Some of 'a=A0=A0 = (* block of size 1 =3D [(header =3D 1 word) + (1 field =3D 1 word)] =3D 2 w= ords *)

2014/1/17 David House &l= t;dhouse@janestr= eet.com>
It behaves identically to that type.

It= is just like any other sum type. However, due to the way that sum types ar= e represented in memory, it is not that inefficient. The only thing that ma= kes it less efficient than a C pointer is the header block (necessary for t= he GC). An option value always takes two words: one for the header, and the= n either a pointer or a word that means "None".


On 17 January 2014 07:35, Damien Guichard <alphablock@orange.fr= > 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. =A0Subscription management and archives:
ht= tps://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



--001a113a5fb63addf004f0267d53--