From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2G8q8uB012216 for ; Wed, 16 Mar 2011 09:52:08 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusCABoXgE3RVaE2kGdsb2JhbACEPpRRjHAIFAEBAQEJCQ0HFAQhpWmKAoJahUKJCgEBAwWCd4FwdgSMXoNNdIQ4OoEa X-IronPort-AV: E=Sophos;i="4.63,193,1299452400"; d="vcf'?scan'208";a="78327186" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Mar 2011 09:52:02 +0100 Received: by fxm11 with SMTP id 11so2215803fxm.27 for ; Wed, 16 Mar 2011 01:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :content-type; bh=+kVYp7xCpDSDdgCl8+7ZcPiXx7p8Xf+JsPUGSZPfewA=; b=xyPrQnOxa73M8TV+qm6N1G/AId4HNFxVAL0/QQtY1f4UaRkRYOUEc3QnH6Tt0WOiTa XSr/oIgQDLeYSCqkyKBKtxCjZae9smjK8P/VdH+SK1/RFKtpIUtDwwKu1oD6qzHL+16R fyDvHx1jVqdZ9Hp07dsRDuoxrLMZqcOTqdGxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=uxW7c6BXU0VAbBZd4XIZpBp9CTzIjk6g6Uo+R5FjFx6RODVJqDoQurbZd6H4SlpSlR r+ZDcoKaLXUDgC9RWrYIaZKPsMMFREzkScNqSkPo8KWfCMvf8PfQ+/RhmzwVbw15w3t4 bAWc/eCoAuYmciq2AfDREcq0QTGpwc94LhRks= Received: by 10.223.77.24 with SMTP id e24mr599123fak.61.1300265220101; Wed, 16 Mar 2011 01:47:00 -0700 (PDT) Received: from [195.83.212.218] (chercheurs-218.saclay.inria.fr [195.83.212.218]) by mx.google.com with ESMTPS id l3sm1528588fan.2.2011.03.16.01.46.56 (version=SSLv3 cipher=OTHER); Wed, 16 Mar 2011 01:46:57 -0700 (PDT) Sender: Fabrice Le Fessant Message-ID: <4D8078FF.2050503@inria.fr> Date: Wed, 16 Mar 2011 09:46:55 +0100 From: Fabrice Le Fessant User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: caml-list@inria.fr References: <057400AC-9E39-45CC-AB7A-35C67C339F83@math.harvard.edu> <325023989.96091.1300242147328.JavaMail.root@zmbs4.inria.fr> In-Reply-To: <325023989.96091.1300242147328.JavaMail.root@zmbs4.inria.fr> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------010706040405090300090507" Subject: Re: [Caml-list] obj magic performance and other questions This is a multi-part message in MIME format. --------------010706040405090300090507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Well, actually, pattern matching is compiled to optimize access to fields depending on their types, so the version without Obj is probably actually faster than the version with Obj. Also, the test with 254 should probably not be removed, as records can also be represented using double arrays (actually, your record rec3 will be represented as a double_array). That's the reason why using Obj to optimize code is often not a very good idea, as you lose the type information, and type information is important for faster access to data structures. --Fabrice On 03/16/2011 03:22 AM, Guillaume Yziquel wrote: > Le Tuesday 15 Mar 2011 à 12:05:31 (-0400), Nicolas Ojeda Bar a écrit : >> Hello, >> >> This is not very efficient. I can use Obj.magic to access that same field as >> follows: >> >> let rec2_b x = >> Obj.obj (Obj.field (Obj.field (Obj.repr x.children 0) 0)) > > Seems that you messed up some parentheses. > >> My question is: is this use of Obj safe? and is this compiled to (two) simple >> array accesses? Or is Obj.obj doing something behind the scenes? > > yziquel@seldon:~/sandbox/ocaml$ cat a.ml > let f x = Obj.obj (Obj.field (Obj.field (Obj.repr x) 0) 0) > yziquel@seldon:~/sandbox/ocaml$ ocamlopt -c -S -dlambda a.ml > (seq > (let > (f/1030 > (function x/1031 > (id (array.unsafe_get (array.unsafe_get (id x/1031) 0) 0)))) > (setfield_imm 0 (global A!) f/1030)) > 0a) > > So it should be compiled to array accesses. However, they are not so > simple array accesses due to OCaml data layout. Moreover, there's this > 'id' around. Let's see: > > yziquel@seldon:~/sandbox/ocaml$ cat a.s > > [...] > > camlA__f_1030: > subq $8, %rsp > .L103: > movq %rax, %rdi > movzbq -8(%rdi), %rax > > So the stack has been managed, and the %rax registers now contains the > tag of the 'x' argument to 'f'. > > cmpq $254, %rax > > This checks that the tag is or isn't the tag of an array of doubles. > (Obj.double_array_tag is 254). So we shouldn't jump on the ext 'je'. > > je .L102 > movq (%rdi), %rbx > > The register %rbx now contains the first field of 'x'. > > jmp .L101 > > [...] > > .L101: > movzbq -8(%rbx), %rax > > This looks at the tag of the first field of 'x', and checks below if it > is an array of doubles. > > cmpq $254, %rax > je .L100 > movq (%rbx), %rax > > %rax now contains the first field of the first field of 'x'. > > addq $8, %rsp > ret > > And 'f' returns with what you want. > > So, aside from checking if tag is 254, it's essentially two direct array > accesses, and the 'id' function of Obj.repr and Obj.obj is erased. > > external repr : 'a -> t = "%identity" > external obj : t -> 'a = "%identity" > external field : t -> int -> t = "%obj_field" > > You could probably hack the compiler to avoid the tag checking if you > really wanted to avoid the 254 test. That'd require another "%..." to be > implemented I guess. > >> Thanks! >> N > --------------010706040405090300090507 Content-Type: text/x-vcard; charset=utf-8; name="fabrice_le_fessant.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fabrice_le_fessant.vcf" begin:vcard fn:Fabrice LE FESSANT n:LE FESSANT;Fabrice org:INRIA Saclay -- Ile-de-France;Projet OCamlPro adr;quoted-printable:;;Parc Orsay Universit=C3=A9 ;Orsay CEDEX;;91893;France email;internet:fabrice.le_fessant@inria.fr title;quoted-printable:Charg=C3=A9 de Recherche tel;work:+33 1 74 85 42 14 tel;fax:+33 1 74 85 42 49 url:http://fabrice.lefessant.net/ version:2.1 end:vcard --------------010706040405090300090507--