From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id A11DBBC69 for ; Sun, 24 Jun 2007 20:51:03 +0200 (CEST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5OIp3A9021195 for ; Sun, 24 Jun 2007 20:51:03 +0200 Received: by ug-out-1314.google.com with SMTP id p27so1054308ugc for ; Sun, 24 Jun 2007 11:51:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=OEeKUtCyd4ndEEjT4B5/quZKWPOaTYF8RSBy6YXUy14J5me/JqZhWSexPAptf7pzF4CDE6Ocv7G7hmCSrSsr/oGvVOCpaDNDarnytVZQlCnsHzuD9ySiJSzIiJDjw4aCOOXCl3V2cbjmvht59McjJHtvfBGKTUs/hJmVN8lRfpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=od/HAUDgbHp4p2/EZJAuq9R3ZXmjx8m5IwA9lHGJhCEvebJaoEro67tzeqOSf6ubC/9bAdimJH0KJqKeAITimxqO0QBUbBSa6Fis+fmykjV559NrpXh0I3izCKuuPxhZNKnip0rkTWk0tb4VFNJpkirppmCLc5y4BoP4ql7iZEg= Received: by 10.67.20.3 with SMTP id x3mr4539951ugi.1182711062918; Sun, 24 Jun 2007 11:51:02 -0700 (PDT) Received: from ?83.248.129.218? ( [83.248.129.218]) by mx.google.com with ESMTP id y6sm17309411mug.2007.06.24.11.51.02 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jun 2007 11:51:02 -0700 (PDT) Message-ID: <467EBD16.7060303@lix.polytechnique.fr> Date: Sun, 24 Jun 2007 20:51:02 +0200 From: Arnaud Spiwack User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Execution time of class versus record References: <467E8A6E.9050700@menta.net> <200706241629.50551.jon@ffconsultancy.com> <9d3ec8300706240848o6ac94a29q67f32d4774c88e0e@mail.gmail.com> <467E9676.50905@lix.polytechnique.fr> <1182709750.20268.22.camel@localhost.localdomain> In-Reply-To: <1182709750.20268.22.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Sender: Arnaud Spiwack X-Miltered: at discorde with ID 467EBD17.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lix:01 runtime:01 compilation:01 compilation:01 ocaml:01 runtime:01 namespaces:01 gerd:01 stolpmann:01 subtyping:01 subtypes:01 ocaml:01 -dlambda:01 seq:01 pervasives:01 Well, this was quite a misunderstanding of my question. Obviously objects are not records. But the essential difference seems to be more at type level (btw object coercion should never cost anything since they are merely type level tools). At runtime, I can't see anything to preven objects to be exactly records (with a bit of care taken during compilation for method names). John Skaller's answer is not really convincing either, since the type of a value does not change the size of the value, having the same name associated to different types does not seem to me a good motivation. I was referring earlier to Xavier Leroy's technical report, I can't remember precisely what the principle was, but there was some sort of label compilation for records with shared names. I tend to remember that it used a sparse encoding of records (with holes corresponding to the missing labels), thus it might have been a problem, but I believe the representation was rather dense in case of only-unique-name-based record. Another lead is maybe something due to module compilation, the earlier idea might imply that each module has it's own namespace (it's the case for almost everything in OCaml, except, if I'm not mistaking, method names). If it is the motivation for having a runtime representation of objects different to that of records, the question that raises nex is: what is the motivation for not having module-specific namespaces for method names? Arnaud Spiwack Gerd Stolpmann a écrit : > Am Sonntag, den 24.06.2007, 18:06 +0200 schrieb Arnaud Spiwack: > >> Which obviously raises the question: What is the motivation for the >> object to be encoded differently than records? >> > > Objects support subtyping whereas records do not. And coercion costs > nothing, thanks to the object representation. > > E.g. > > let print_m2 obj = print_string obj#m2 > > let x1 = object method m2 = "x1" method m3 = 42 end > > let x2 = object method m1 = 98 method m2 = "x2" end > > print_m2 x1 > print_m2 x2 > > See that in x1 the called method m2 is the first in the list, and in x2 > it is the second? In a record the order of the components in the memory > layout is the same as the order in the type. If we did that the same > with objects, we would have to do rearrangements when we coerce objects > to supertypes (which happens here when print_m2 is called). > > Note also that object types are structural and not nominal as for many > object-oriented languages (i.e. you don't have to declare that x1 and x2 > will be used as subtypes of ). > > >> I remember reading in >> Xavier Leroy's technical report about the first ZAM how he prepared the >> field for extensible records (to be able to implement objects). There >> the name of the fields were compiled into an adress, resulting no >> runtime conversion. >> >> I can imagine a couple of applications to the current situation (though >> I'm not so sure they would work), but I'm really interested in the >> original reason of this design choice. >> >> >> Arnaud Spiwack >> >> >> >> Till Varoquaux a écrit : >> >>> Objects in OCaml are dictionary based, which means methods names must >>> be looked up in a table in order to get there addresses. Record fields >>> on the other hand are addressed directly. Take two files test.ml and >>> test2.ml: >>> test.ml: >>> type b= >>> { >>> field:int >>> } >>> let a={field=1};; >>> print_int a.field >>> >>> test2.ml >>> let a=object >>> method field=1 >>> end;; >>> print_int a#field >>> >>> and dump there intermediate representation (-dlambda) >>> >>> test.ml >>> >>> (setglobal Test! >>> (let (a/61 [0: 1]) >>> (seq (apply (field 27 (global Pervasives!)) (field 0 a/61)) >>> (makeblock 0 a/61)))) >>> >>> test2.ml >>> >>> (setglobal Test2! >>> (let >>> (a/58 >>> (let >>> (class/72 (apply (field 15 (global CamlinternalOO!)) [0: >>> #"field"]) >>> obj_init/80 >>> (let >>> (field/61 >>> (apply (field 6 (global CamlinternalOO!)) class/72 >>> #"field")) >>> (seq >>> (apply (field 10 (global CamlinternalOO!)) class/72 >>> (makeblock 0 field/61 0a 1)) >>> (function env/74 >>> (apply (field 23 (global CamlinternalOO!)) 0a >>> class/72))))) >>> (seq (apply (field 16 (global CamlinternalOO!)) class/72) >>> (apply obj_init/80 0a)))) >>> (seq (apply (field 27 (global Pervasives!)) (send a/58 9671866)) >>> (makeblock 0 a/58)))) >>> >>> You can now understand where the performance issues comes from. >>> >>> Cheers, >>> Till >>> On 6/24/07, Jon Harrop wrote: >>> >>>> On Sunday 24 June 2007 16:14:54 tmp123@menta.net wrote: >>>> >>>>> Hello, >>>>> >>>>> I've tried to implement two equivalent small programs, the one using >>>>> class, the other one using records. The resulting execution times says >>>>> that class are 7-8 times slower than record (compiled with ocamlopt >>>>> >>>> in a >>>> >>>>> Intel machine). >>>>> >>>>> Please, knows someone what I'm doing wrong? >>>>> >>>> You aren't doing anything wrong. >>>> >>>> -- >>>> Dr Jon D Harrop, Flying Frog Consultancy Ltd. >>>> The OCaml Journal >>>> http://www.ffconsultancy.com/products/ocaml_journal/?e >>>> >>>> _______________________________________________ >>>> Caml-list mailing list. Subscription management: >>>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >>>> Archives: http://caml.inria.fr >>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>>> Bug reports: http://caml.inria.fr/bin/caml-bugs >>>> >>>> >>> >> _______________________________________________ >> Caml-list mailing list. Subscription management: >> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >> Archives: http://caml.inria.fr >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >>