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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 6BA4F7EDC3 for ; Tue, 20 Nov 2012 11:26:12 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of pierre.chambart@ocamlpro.com) identity=pra; client-ip=138.231.136.39; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="pierre.chambart@ocamlpro.com"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of pierre.chambart@ocamlpro.com) identity=mailfrom; client-ip=138.231.136.39; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="pierre.chambart@ocamlpro.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of postmaster@redisdead.crans.org designates 138.231.136.39 as permitted sender) identity=helo; client-ip=138.231.136.39; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="postmaster@redisdead.crans.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4DAD9aq1CK54gngWdsb2JhbAA8CbATkkQjAQEWJieCHgEBBAEnEzQQCwsYDSFFEhkSh2kDCQYEB698hnYDiV6LSGkRhGQDlCuBUAGBHIoWiAE X-IronPort-AV: E=Sophos;i="4.83,284,1352070000"; d="scan'208";a="182306169" Received: from redisdead.crans.org ([138.231.136.39]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 20 Nov 2012 11:25:25 +0100 Received: from localhost (abo-30-238-68.guy.modulonet.fr [85.68.238.30]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by redisdead.crans.org (Postfix) with ESMTPSA id C402720FE for ; Tue, 20 Nov 2012 11:25:24 +0100 (CET) Date: Tue, 20 Nov 2012 11:25:19 +0100 From: Pierre Chambart To: caml-list@inria.fr Message-ID: <20121120112519.2e155a09@crans.org> In-Reply-To: References: <1353347369.78785.YahooMailNeo@web111510.mail.gq1.yahoo.com> <50AA7427.5080104@etorok.net> <1353349126.4420.YahooMailNeo@web111512.mail.gq1.yahoo.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Validation-by: pierre.chambart@ocamlpro.com Subject: Re: [Caml-list] The verdict on "%identity" To know what will be generated after inlining I prefer to use -dcmm, which is closer to the original code than the assembly and still show show inlining result (and if you are using the svn trunk, you can use -dclambda which show a higher level code, without allocations and boxing). Inlining of OCaml functions works the same way inside a module or cross-module. It looks at the function size and if it smaller than a certain threshold, it will be inlined. To know if it will happen to your function, look at the result of ocamlobjinfo. for instance: module.mli: type t external id_prim : string -> t = "%identity" val id : string -> t val f : int -> int val g : int -> int module.ml: type t = string external id_prim : 'a -> 'a = "%identity" let id x = x let f x = x + x + x + x let g x = x + x + x + x + x + x + x + x ocamlobjinfo module.cmx: ... Approximation: (0: function camlIdentity__id_1010 arity 1 (closed) (inline) -> _; 1: function camlIdentity__f_1012 arity 1 (closed) (inline) -> _; 2: function camlIdentity__g_1014 arity 1 (closed) -> _) ... the function id and f will be inlined whatever the context of the call is, but g won't be. If you want a function to be inlined, you can use the -inline option of ocamlopt to increase the maximum size of inlined functions in the module. Notice that recursive functions can't be inlined. The usage of private type is different. When using generic comparison/equality/hash/set in an array, the compiler generate an optimised code when the type is known to be one of the fast cases: module M1 : sig type t = private int end = struct type t = int end module M2 : sig type t end = struct type t = int end let a x y = x > y let b (x:int) y = x > y let c (x:M1.t) y = x > y let d (x:M2.t) y = x > y the result of ocamlopt -dcmm: (function camlCompare__a_1014 (x/1015: addr y/1016: addr) (extcall "caml_greaterthan" x/1015 y/1016 addr)) (function camlCompare__b_1017 (x/1018: addr y/1019: addr) (+ (<< (> x/1018 y/1019) 1) 1)) (function camlCompare__c_1020 (x/1021: addr y/1022: addr) (+ (<< (> x/1021 y/1022) 1) 1)) (function camlCompare__d_1023 (x/1024: addr y/1025: addr) (extcall "caml_greaterthan" x/1024 y/1025 addr)) Here b and c will be a lot faster than a and d. Using private type allows to keep those informations acros modules. -- Pierre Le Mon, 19 Nov 2012 18:28:32 +0000, David House wrote : > If you wanted to investigate this yourself, you could compile with -S > and look at the generated assembly. For such short functions, this is > generally not very hard. > > On Mon, Nov 19, 2012 at 6:18 PM, Dario Teixeira > wrote: > > Hi, > > > >> Wouldn't 'type t = private string' help the compiler optimize this? > > > > > > Possibly, though the semantics would change: what before was > > an abstract type is now translucent (ie, not quite transparent). > > > > Regards, > > Dario > > > > -- > > 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 >