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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 5C8AD8027D for ; Wed, 25 Oct 2017 11:44:58 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-qk0-f170.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.220.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.220.170 as permitted sender) identity=mailfrom; client-ip=209.85.220.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.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@mail-qk0-f170.google.com) identity=helo; client-ip=209.85.220.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-qk0-f170.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3ArCIf/xEypM7LnAkQgMH3up1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ75psuwAkXT6L1XgUPTWs2DsrQf1LqQ7viocFdDyKjCmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWapAQfERTnNAdz?= =?us-ascii?q?Ov+9WsuL15z2hKiO/Mj4Yx9Jnya6ebNFDIu5oB+Z4sIWm4p5NqEpyl3JpXZHdv?= =?us-ascii?q?5+zm5sKEiamBDxoMy3+cgw3T5XvqcO/sRaUKj+N58zTbFCAS5uZ2887tfquB2F?= =?us-ascii?q?VgCP62ERSE0ZlxNJB07O6xSsDcS5iTfzqucogHrSBsbxV71hHG36t6o=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AwDyW/BZhqrcVdFaHQEFAQsBFwEBB?= =?us-ascii?q?AEBCgEBhQYnB4NzgTaYHYF6iTuND4IBCoU7AoRiB0QTAQEBAQEBAQEBAQESAQE?= =?us-ascii?q?BCAsLCCgvgjgFAR4BBYI8AQQBIx0BGx0BAwELBgMCCzcCAiIBEQEFARwGE4oHA?= =?us-ascii?q?QMNCItRkRtAjAyCBQUBHIMJBYNnChknDViCbAEBAQEGAQEBAQEbAgYSgxyCB4F?= =?us-ascii?q?QhROETYNMgmEFoXOCL5JIkyaVbRQFH4EVN4F7NCElXjWCL4JNH4F1PjaKR4FVA?= =?us-ascii?q?QEB?= X-IPAS-Result: =?us-ascii?q?A0B6AwDyW/BZhqrcVdFaHQEFAQsBFwEBBAEBCgEBhQYnB4N?= =?us-ascii?q?zgTaYHYF6iTuND4IBCoU7AoRiB0QTAQEBAQEBAQEBAQESAQEBCAsLCCgvgjgFA?= =?us-ascii?q?R4BBYI8AQQBIx0BGx0BAwELBgMCCzcCAiIBEQEFARwGE4oHAQMNCItRkRtAjAy?= =?us-ascii?q?CBQUBHIMJBYNnChknDViCbAEBAQEGAQEBAQEbAgYSgxyCB4FQhROETYNMgmEFo?= =?us-ascii?q?XOCL5JIkyaVbRQFH4EVN4F7NCElXjWCL4JNH4F1PjaKR4FVAQEB?= X-IronPort-AV: E=Sophos;i="5.43,431,1503352800"; d="scan'208,217";a="242296254" Received: from mail-qk0-f170.google.com ([209.85.220.170]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 25 Oct 2017 11:44:57 +0200 Received: by mail-qk0-f170.google.com with SMTP id m189so29671904qke.4 for ; Wed, 25 Oct 2017 02:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6NlJmUfQhaOVOOVAtN0U2c6oXl65FHmEze4t8vBxxZ0=; b=ts7tycrNKmjpRkgq0RaeXXL5UmfvBu0ZjyyC5KZ/x/uCFjla/JNt9Pa9+i86sujpiq RgoDLSui430mDMkeLsDgVzZiKMGXZrISc2ISGhSzVCLBQUGrDfgHBOeT/8TZjxzTM/K1 o5nwHZMNFZxqfEDTm+LGKUPF7Q0vJfiMZkHFuX/nzUuM+zQTT6njOMLDMHW9RxJRukC7 h/nEn6PDoZlS3oqTBOo+m7LuLXHmKaLRupHbs+f43EfQCtQphj8AyqRhYhhiy/yfC65E Wo8nJho7CNrf6XWir5N04OKe1cd1AKLKGO4odxKdijDIsDvZmKFu6mLF6e8Pryz4peRF KuGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6NlJmUfQhaOVOOVAtN0U2c6oXl65FHmEze4t8vBxxZ0=; b=V7UguhAJjrFofWL8IicXo36hz+Lro1FhKDqqjG2NR4IsEeHa6FkNetWnxYEjbLuigw FsDEp8dMCxjLzTzz24hGtZddzJj2H8WVr3X2R3qmGTKDZdi+9ne+dUEh4P4t/ppr2vfJ 1992VOKrHQ+NLxKiZMLSZRfDWMy0fEtdHR/yFHCT7LEW/XNEJ+EQCyG+pcFVyiwWE7S+ oV0YCxZuFsOoViCiFU4r8w9qE95MrODhHboPTfnuVQQHWrgWwgiPEOWL0DtC3kvcwzGX H1poQpdZmziA1G+Vi2KEUiSToHidGG9cTUnEw5io/PhHoeBCqWZHxADebS23H3PPyqOF uQ8Q== X-Gm-Message-State: AMCzsaUZAQ1KZg0Wa8q2FH9rRjqivHNh6rS3Nqp9ZrXlZoAnNnFR73tv JdIq9RBBVjjJ5jeftG29CvfWTMVNNpv5R+NCk5HM/A== X-Google-Smtp-Source: ABhQp+RkK7yZL5w43XlP0jQZACyDTImMrMNj3cJEikvnhQtIl6qZ1Q3ksVWX/5ooMZjAU/sqd7vwA5MWkXIW0Sr7nCo= X-Received: by 10.55.153.69 with SMTP id b66mr2110728qke.107.1508924696306; Wed, 25 Oct 2017 02:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.178.65 with HTTP; Wed, 25 Oct 2017 02:44:15 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Wed, 25 Oct 2017 11:44:15 +0200 Message-ID: To: =?UTF-8?Q?Christoph_H=C3=B6ger?= Cc: OCaml Mailing List Content-Type: multipart/alternative; boundary="94eb2c07ecee84277c055c5be8f8" Subject: Re: [Caml-list] classes not optimized? --94eb2c07ecee84277c055c5be8f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Object-oriented code tends to generate large intermediate representations, too large to be inlined and too complex to be partially evaluated at compile-time. I wouldn't expect this sort of optimization to work. You might have better luck with first-class modules if you want some sort of tuple subtyping. (Performance model: with modules, subtyping coercions are compiled as a field-reordering copy, so the runtime cost is on the coercion rather than the field access.) > Also as a related question, is there a way to have the lookup semantics of methods without the open recursion part? We could add row-typed extensible records to the language. Given how little the object-oriented layer is used in practice, I am not sure that this highly work-demanding addition would be a good use of a contributor's time -- and its utility would have to be weighted against the complexity cost of adding yet another kind of product structure. On Wed, Oct 25, 2017 at 11:31 AM, Christoph H=C3=B6ger < christoph.hoeger@celeraone.com> wrote: > Dear OCaml users, > > consider the following microbenchmark: > > > class s (z : string) (y : int) (x : int) =3D > object method z =3D z method y =3D y method x =3D x > end > > type t =3D { x : int; y : int; z : string} > > let foo_s _ =3D > (new s) "Example" 0 1 > > let foo_t _ =3D {x=3D1; y=3D0; z=3D"Example"} > > let one_s _ =3D (foo_s ())#x > > let one_t _ =3D (foo_t ()).x > > let fac =3D > let rec fac n =3D > let f =3D > let rec f n a =3D if n <=3D 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 =3D > let rec bench n a =3D > if n <=3D 0 > then a > else (let x =3D a && ((fac 20) =3D=3D (20 * (fac 19))) in bench (n -= 1) x) > in > bench > let test =3D bench 10000000 true > let main _ =3D 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 inlin= ed? > > 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 > > --94eb2c07ecee84277c055c5be8f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Object-oriented code tends to generate large int= ermediate representations, too large to be inlined and too complex to be pa= rtially evaluated at compile-time. I wouldn't expect this sort of optim= ization to work.

You might have better luck with first-class m= odules if you want some sort of tuple subtyping.
(Performance model: wit= h modules, subtyping coercions are compiled as a field-reordering copy,
= so the runtime cost is on the coercion rather than the field access.)
> Also as a related question, is there a way to have the lookup semant= ics of methods without the open recursion part?

We could add r= ow-typed extensible records to the language. Given how little the object-or= iented layer is used in practice, I am not sure that this highly work-deman= ding addition would be a good use of a contributor's time -- and its ut= ility would have to be weighted against the complexity cost of adding yet a= nother kind of product structure.

<= div class=3D"gmail_quote">On Wed, Oct 25, 2017 at 11:31 AM, Christoph H=C3= =B6ger <christoph.hoeger@celeraone.com> wrote:<= br>
Dear OCaml users,

consider the following microbenchmark:
<= /div>

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

type t =3D { x : int; y : int; z : strin= g}

let foo_s _ =3D
=C2=A0(new s) "Example" 0 1

l= et foo_t _ =3D {x=3D1; y=3D0; z=3D"Example"}

let one_s _ = =3D (foo_s ())#x

let one_t _ =3D (foo_t ()).x

let fac =3D
= =C2=A0 let rec fac n =3D
=C2=A0=C2=A0=C2=A0 let f =3D
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 let rec f n a =3D if n <=3D 1 then a else f (n - (one_s = ())) (n * a)=C2=A0 in f (* change one_t to one_s or vice-versa *)
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in
=C2=A0=C2=A0=C2=A0 f n 1=C2=A0 in
= =C2=A0 fac
let bench =3D
=C2=A0 let rec bench n a =3D
=C2=A0=C2=A0= =C2=A0 if n <=3D 0
=C2=A0=C2=A0=C2=A0 then a
=C2=A0=C2=A0=C2=A0 el= se (let x =3D a && ((fac 20) =3D=3D (20 * (fac 19)))=C2=A0 in bench= (n - 1) x)=C2=A0 in
=C2=A0 bench
let test =3D bench 10000000 truelet main _ =3D 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 c= onsists of values, not methods? It would love to have open tuples in some c= ases. For example, I'd like to write a function that takes a tuple of a= ny length, because it only needs the first element.

thanks,
Christoph
=C2=A0

--94eb2c07ecee84277c055c5be8f8--