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 5282A7F61E for ; Wed, 8 Nov 2017 22:45:29 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=misterherr@freenet.de; spf=None smtp.mailfrom=misterherr@freenet.de; spf=None smtp.helo=postmaster@mout3.freenet.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of misterherr@freenet.de) identity=pra; client-ip=195.4.92.93; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="misterherr@freenet.de"; x-sender="misterherr@freenet.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of misterherr@freenet.de) identity=mailfrom; client-ip=195.4.92.93; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="misterherr@freenet.de"; x-sender="misterherr@freenet.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout3.freenet.de) identity=helo; client-ip=195.4.92.93; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="misterherr@freenet.de"; x-sender="postmaster@mout3.freenet.de"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AgdVeBxdmFLl5vMMa25PpJRNHlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxc2/Yh7h7PlgxGXEQZ/co6odzbGJ4+a9ASQp2tWojjMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpW1aJhKqPgNw?= =?us-ascii?q?IqHxG5XOp8WxzeG7vZPJMCtSgz/oK5Zoal2WoB/L/IFChIp5NqsryhbTuFNGYe?= =?us-ascii?q?lbw250Y16eyUWvrvys9YJupnwD88kq8NRNBP33?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAwCveQNah11cBMNcHAEBAQQBAQoBA?= =?us-ascii?q?YJmgTVrhCSZRIFWJhCQdIVYggEKhTsChHxDFAEBAQEBAQEBAQESAQEBCA0JCCg?= =?us-ascii?q?vgjgigkUBAgMjZgkCGCoCAlcTCAEBigYBGQMBjDmdaIInJoZWCYEyAYJjAQEIA?= =?us-ascii?q?QEBASSDMIIHg2YLgnaEXYNNgmMFohoCgQmfZwWHP5YhgTk2ghJ7XYJlgmuBdI0?= =?us-ascii?q?AAQEB?= X-IPAS-Result: =?us-ascii?q?A0AEAwCveQNah11cBMNcHAEBAQQBAQoBAYJmgTVrhCSZRIF?= =?us-ascii?q?WJhCQdIVYggEKhTsChHxDFAEBAQEBAQEBAQESAQEBCA0JCCgvgjgigkUBAgMjZ?= =?us-ascii?q?gkCGCoCAlcTCAEBigYBGQMBjDmdaIInJoZWCYEyAYJjAQEIAQEBASSDMIIHg2Y?= =?us-ascii?q?LgnaEXYNNgmMFohoCgQmfZwWHP5YhgTk2ghJ7XYJlgmuBdI0AAQEB?= X-IronPort-AV: E=Sophos;i="5.44,365,1505772000"; d="scan'208,217";a="299979793" Received: from mout3.freenet.de ([195.4.92.93]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-GCM-SHA256; 08 Nov 2017 22:45:28 +0100 Received: from [195.4.92.140] (helo=mjail0.freenet.de) by mout3.freenet.de with esmtpa (ID misterherr@freenet.de) (port 25) (Exim 4.89 #1) id 1eCYA3-0000yL-OL for caml-list@inria.fr; Wed, 08 Nov 2017 22:45:27 +0100 Received: from [::1] (port=47936 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID misterherr@freenet.de) (Exim 4.89 #1) id 1eCYA3-0003KE-KH for caml-list@inria.fr; Wed, 08 Nov 2017 22:45:27 +0100 Received: from mx3.freenet.de ([195.4.92.13]:32920) by mjail0.freenet.de with esmtpa (ID misterherr@freenet.de) (Exim 4.89 #1) id 1eCY6y-0005LY-5Q for caml-list@inria.fr; Wed, 08 Nov 2017 22:42:16 +0100 Received: from x4dbb651c.dyn.telefonica.de ([77.187.101.28]:35258 helo=[192.168.3.43]) by mx3.freenet.de with esmtpsa (ID misterherr@freenet.de) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (port 465) (Exim 4.89 #1) id 1eCY6x-0001Mr-Uj for caml-list@inria.fr; Wed, 08 Nov 2017 22:42:16 +0100 To: caml-list@inria.fr References: From: "Mr. Herr" Message-ID: <95172d76-724c-3da2-7329-bc9f97400f27@freenet.de> Date: Wed, 8 Nov 2017 22:42:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------29DDFC37274593785E9AD637" Content-Language: en-GB X-Originated-At: 77.187.101.28!35258 Subject: Re: [Caml-list] classes not optimized? This is a multi-part message in MIME format. --------------29DDFC37274593785E9AD637 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Dear list readers, to me it seems this benches only the object creation, not the method dispatch. So the main result here is that object creation is quite expensive, and record field selection is 2 times faster than getting a value by a method. Just change foo_s to a constant class instance removing the _ parameter. Max On 25.10.2017 11:31, Christoph Höger wrote: > Dear OCaml users, > > consider the following microbenchmark: > > > class s (z : string)  (y : int)  (x : int) = >   object method z = z method y = y method x = x > end > > type t = { x : int; y : int; z : string} > > let foo_s _ = >  (new s) "Example" 0 1 > > let foo_t _ = {x=1; y=0; z="Example"} > > let one_s _ = (foo_s ())#x > > let one_t _ = (foo_t ()).x > > let fac = >   let rec fac n = >     let f = >       let rec f n a = if n <= 1 then a else f (n - (one_s ())) (n * a)  in f (* > change one_t to one_s or vice-versa *) >        in >     f n 1  in >   fac > let bench = >   let rec bench n a = >     if n <= 0 >     then a >     else (let x = a && ((fac 20) == (20 * (fac 19)))  in bench (n - 1) x)  in >   bench > let test = bench 10000000 true > let main _ = test > > > If I run it with ocamlopt 4.05.0+flambda and -O3, the version that uses one_s takes > about 7.5s whereas the one with one_t uses 0.35s. I know that object method lookup > is more costly than records, of course. This particular case baffles me, though. > Why is the class not completely inlined? > > Also as a related question, is there a way to have the lookup semantics of methods > without the open recursion part? That is, can I have a class that consists of > values, not methods? It would love to have open tuples in some cases. For example, > I'd like to write a function that takes a tuple of any length, because it only > needs the first element. > > thanks, > > Christoph >   --------------29DDFC37274593785E9AD637 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear list readers,

to me it seems this benches only the object creation, not the method dispatch.

So the main result here is that object creation is quite expensive, and record field selection is 2 times faster than getting a value by a method.

Just change foo_s to a constant class instance removing the _ parameter.


Max


On 25.10.2017 11:31, Christoph Höger wrote:
Dear OCaml users,

consider the following microbenchmark:

<snip>
class s (z : string)  (y : int)  (x : int) =
  object method z = z method y = y method x = x
end

type t = { x : int; y : int; z : string}

let foo_s _ =
 (new s) "Example" 0 1

let foo_t _ = {x=1; y=0; z="Example"}

let one_s _ = (foo_s ())#x

let one_t _ = (foo_t ()).x

let fac =
  let rec fac n =
    let f =
      let rec f n a = if n <= 1 then a else f (n - (one_s ())) (n * a)  in f (* change one_t to one_s or vice-versa *)
       in
    f n 1  in
  fac
let bench =
  let rec bench n a =
    if n <= 0
    then a
    else (let x = a && ((fac 20) == (20 * (fac 19)))  in bench (n - 1) x)  in
  bench
let test = bench 10000000 true
let main _ = test
</snip>

If I run it with ocamlopt 4.05.0+flambda and -O3, the version that uses one_s takes about 7.5s whereas the one with one_t uses 0.35s. I know that object method lookup is more costly than records, of course. This particular case baffles me, though. Why is the class not completely inlined?

Also as a related question, is there a way to have the lookup semantics of methods without the open recursion part? That is, can I have a class that consists of values, not methods? It would love to have open tuples in some cases. For example, I'd like to write a function that takes a tuple of any length, because it only needs the first element.

thanks,

Christoph
 

--------------29DDFC37274593785E9AD637--