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 AD9907F026 for ; Thu, 10 Mar 2016 23:52:03 +0100 (CET) IronPort-PHdr: 9a23:ZnBhghYqzbjf5R1lz7UAkdj/LSx+4OfEezUN459isYplN5qZpM27bnLW6fgltlLVR4KTs6sC0LqJ9fCwEjVdv96oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDtvc2DKFwV2nKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQezCS/WMRWXk6lR9BAg6NrE2rH8S5jiyvjutwwjOXdeb2RLU+UC6+p/NzSRLykipBPD4w9WvekNBYiKtDpwm9qlp5zpKCM6+PM/8rUa7HcZshWW1FRsNYUSoJVoK6YYwnAOcbMaNDs475v14Hqx34CQT6V7Cn8SNBmnKjhf5y6O8mCwyTmVF5Eg== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=info@gerd-stolpmann.de; spf=None smtp.mailfrom=info@gerd-stolpmann.de; spf=None smtp.helo=postmaster@mout.kundenserver.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.134; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.134; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.126.134; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4AAAu+uFWi4Z+49RehBBtqiuJAIUnghMBDYFtFwqFbgKBQDgUAQEBAQEBAQEQAQEBCAsLCR8xgi2CFAEBAQMBVRkLBQsLGA0hISQSBhMJCYd9AwoMAQm5BgMKhD8BAQEBAQEEAQEBAQEBEgiFIIQ8foI9gUwMMII9S4EnBYYeDIEzj1+BLQKEO4YZgXWBZEuGegQjhS+HGodQHgEBglaBUWkBiRaBOgEBAQ X-IPAS-Result: A0A4AAAu+uFWi4Z+49RehBBtqiuJAIUnghMBDYFtFwqFbgKBQDgUAQEBAQEBAQEQAQEBCAsLCR8xgi2CFAEBAQMBVRkLBQsLGA0hISQSBhMJCYd9AwoMAQm5BgMKhD8BAQEBAQEEAQEBAQEBEgiFIIQ8foI9gUwMMII9S4EnBYYeDIEzj1+BLQKEO4YZgXWBZEuGegQjhS+HGodQHgEBglaBUWkBiRaBOgEBAQ X-IronPort-AV: E=Sophos;i="5.24,317,1454972400"; d="asc'?scan'208";a="207112365" Received: from mout.kundenserver.de ([212.227.126.134]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2016 23:52:02 +0100 Received: from office1.lan.sumadev.de ([188.110.5.208]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0MNhcI-1alGyQ3s9i-0079vD; Thu, 10 Mar 2016 23:52:01 +0100 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 31351DC05D; Thu, 10 Mar 2016 23:52:00 +0100 (CET) Message-ID: <1457650315.13223.42.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: Pierre Chambart Cc: Markus Mottl , OCaml List Date: Thu, 10 Mar 2016 23:51:55 +0100 In-Reply-To: <56E1D523.7000701@laposte.net> References: <56DF57FA.9070309@lexifi.com> <56E1D523.7000701@laposte.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-k+4htR0+VPmhgYDT/cbD" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:CQr0ENwylhHB7OsyGOmVhM4Kg6qgr3jmR48RRMUG2gTz41VJoEF Z8VMyZZaJrujbwCMoQB6HXIgwsrwAzB7lEdTS5iEy1EOSQQqF4RDIBWVFAVb0yV72BdA1Dj NeqpGLIMeiPbRURZYoFf7KX5Uh9ne9PdueDPePo4upPPYe9+G2wEBR+r1TdjTyyjPMxa21X vTyzvXBTTOce3B3O9kqwA== X-UI-Out-Filterresults: notjunk:1;V01:K0:RBhysOQURsw=:i8LG9667BycxQHzpP4lLA/ /K97bezYsxnn+bS2Yt58jgDbxZrSobCO+2Th0TnotY+Z7hdlIOvth4igh7soZZc2F+7Bn1teR n4ZYPIeYYI0qyo+hDXYWHjX9hzVjvhA3pNoyvgMYyHgDU8ED85VsN/JrGxBsaHTP772WKkpwW 645x7K9ngBVwRyi2bUQPU5u5C61ptbhAZAvsfZXwj9Iuzk1Gonjl3Qp/a2MsgmKjgocOkTtGF tLeCuFQpNl8hsqswUHeHK70zM8PsSDQDLKva3Md3uvdyk0iht8meIne7jCW3Om7OOYjU/SI6k ajobusdlEMHKFxpPE8ELBbPujL16jA4vhqRMTOAUPgUqnUj06ng113lOyWojTCCwlwBiTjtBZ UWd46kzHtuMqbrrzT++VWphsOCpewPvP0EncRYyDSBIMd0c+RRdNidBWBkasuAw8a6nLKTiRZ qtxUKG9wOMVhYKzfUFqLGj1l1xd3ozfEQqgyYYc7UN5tSX/Em/BaKgV3PYA1fKVTuRMegK311 PsZoj4SoZk1nPbnJTvzkhQwKtwpcTIzaCe1YpYTQgGQ7b5gGoVV2qA5bZT3go0pFBl0U7CwMA icSJAUBdN6BV67aHnw9cJcw3SUj9LbyqIwcJisjKqJebaVSgD2mmilYehPOLemaR6l6P6BC5c MeYzWzNLCFsmqyOQkkdRqSVjt9uq7YuoYrCpme9AhESllWq6dJPtQ/OKABI2tJwq8NPw= Subject: Re: [Caml-list] Re: Status of Flambda in OCaml 4.03 --=-k+4htR0+VPmhgYDT/cbD Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Am Donnerstag, den 10.03.2016, 21:12 +0100 schrieb Pierre Chambart: > It is realistic when using the -Oclassic option that Mark mentioned. > By default the flambda inlining heuristic is decided at call site. Hence > all the information about a function needs to be available to correctly > decide. That means that the size of the cmx file is approximatively > linearly related to the .o file size. It is not easy to decide that some > function will never be inlined, so the information is always kept, > even on function annotated with [@inline never]. This assumes that the user is fine with an unlimited code size blow-up. So, to make an example, when you have let f() =3D if then else there is the chance that the "if-then" part can be inlined and leads to a speed-up at the price that the unproductive "else" part is also inlined. In total, there is a good chance that you see some acceleration. However, the question is whether the code duplication is acceptable or not. I guess, you need to also draw a line at the callee site, and disregard functions that are too large in total (though this limit can be way higher than the limit for "classic" inlining). Surely this will also limit the cmx size somewhat. Gerd > But I wouldn't > expect that to benefit that much. But for the -Oclassic mode where > the decision is made at the definition, it is possible to decide not > to include some information in the cmx. This is what happens in > non-flambda mode, and in flambda mode it also reduce a bit the > cmx size, but not as much as it could. This will probably improve > in 4.04 if there is sufficient interest in this -Oclassic mode. > --=20 > Pierre >=20 > On 10/03/2016 16:32, Markus Mottl wrote: > > Ok, that explains things. Is it realistic to assume that the size of > > .cmx files can be substantially reduced? It seems there is a natural > > tradeoff between "optimize well" and "compile fast". I suspect it may > > be inevitable to add more compilation files. We actually already have > > that situation with native code libraries: the .cmxa file is enough to > > compile a project, but if the .cmx files of contained modules are > > visible in the path, too, then, and only then, the compiler can and > > will do cross-module inlining - which takes longer, of course. > > > > What about the following approach? - There is one "minimal" set of > > compilation files that always allows you to quickly obtain a running > > (albeit slow / large) executable. Additional compilation files then > > monotonically augment this information and can be produced and > > consumed optionally depending on compilation flags. The nice thing > > about this approach is that you don't necessarily have to recompile > > the whole project with different flags whenever you need a different > > compile time / performance tradeoff. E.g. if Flambda information is > > available for an unchanged file, you don't have to rebuild it when > > needed. If you just want to compile quickly, you don't have to read > > data you don't need. Separate compilation files would also integrate > > much better with build tools (timestamping, etc.). > > > > I guess we would already be looking at OCaml version 5 for such a chang= e :) > > > > On Thu, Mar 10, 2016 at 2:20 AM, Mark Shinwell wrote: > >> By "enabled at configure time" I mean that you need to pass the > >> "-flambda" option to the configure script when building the compiler. > >> > >> The main reason Flambda isn't enabled by default is because we need to > >> do further work to improve compile-time performance. There are also > >> concerns about .cmx file size. Flambda produces larger .cmx files: it > >> stores the entire intermediate representation of the compilation unit > >> so that no subsequent cross-module inlining decision is compromised. > >> > >> There is a mode, -Oclassic, which uses Flambda but mimics the > >> behaviour of the existing compiler; unfortunately this isn't really > >> fast enough yet either and .cmx sizes aren't small enough. > >> > >> When we manage to address some of these issues further, hopefully for > >> 4.04, we will revisit whether Flambda should be enabled by default. > >> > >> One of the main reasons there is a configure option rather than a > >> runtime switch is to avoid having to re-engineer the compiler's build > >> system to permit multiple builds of the various libraries (the stdlib, > >> for example) with differing options that affect what appears in the > >> .cmx files (e.g. with and without Flambda). Even if code were used to > >> allow Flambda to read non-Flambda .cmx files, performance degradation > >> would result. > >> > >> Mark > >> > >> On 10 March 2016 at 01:43, Markus Mottl wrote: > >>> I agree with Yotam. Assuming that Flambda produces correct code and > >>> doesn't cause any serious performance issues either with the generated > >>> code or with excessive compile times, I'd prefer building it into the > >>> compiler by default. I'd be fine if I had to pass an extra flag at > >>> compile time to actually run Flambda optimizers, but it should at > >>> least be available. It doesn't have to be perfect to be useful. > >>> > >>> On Wed, Mar 9, 2016 at 8:32 PM, Yotam Barnoy = wrote: > >>>> While we await the manual, can you explain what you mean by 'enabled= at > >>>> configure time'? Will a -flambda -O-something argument passed to the= normal > >>>> 4.03 compiler enable flambda optimizations? Flambda is clearly the s= tar of > >>>> the 4.03 release, so not enabling it using command line options seems > >>>> counter-intuitive (if this is the case). > >>>> > >>>> -Yotam > >>>> > >>>> On Wed, Mar 9, 2016 at 7:59 PM, Markus Mottl wrote: > >>>>> I've just tested Flambda, and it seems to already be doing a pretty > >>>>> decent job on some non-trivial examples (e.g. inlining combinations= of > >>>>> functors and first class functions). I hope there will be a stable > >>>>> 4.03 OPAM switch that enables it. I'm looking forward to being able > >>>>> to write more elegant, abstract code that's still efficient. > >>>>> > >>>>> Regards, > >>>>> Markus > >>>>> > >>>>> On Wed, Mar 9, 2016 at 2:14 AM, Mark Shinwell > >>>>> wrote: > >>>>>> It will not be enabled by default in 4.03. For the majority of > >>>>>> programs, in the current state, it should improve performance (mai= nly > >>>>>> by lowering allocation). It should never generate wrong code. > >>>>>> However we know of examples that don't improve as much as we would > >>>>>> like, which we will try to address for 4.04. > >>>>>> > >>>>>> There will be a draft version of the new Flambda manual chapter > >>>>>> available shortly (hopefully this week). Amongst other things this > >>>>>> documents what you found about the configure options and the flags' > >>>>>> operation. > >>>>>> > >>>>>> Mark > >>>>>> > >>>>>> On 9 March 2016 at 03:55, Markus Mottl wr= ote: > >>>>>>> Hi Alain, > >>>>>>> > >>>>>>> I see, thanks. It was a little confusing, because the command li= ne > >>>>>>> options for tuning flambda were still available even without Flam= bda > >>>>>>> being enabled. > >>>>>>> > >>>>>>> Will Flambda be enabled by default in OCaml 4.03 or is it still > >>>>>>> considered to be too experimental? It could turn out to become o= ne of > >>>>>>> the most impactful new features in terms of how I write code. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Markus > >>>>>>> > >>>>>>> On Tue, Mar 8, 2016 at 5:53 PM, Alain Frisch > >>>>>>> wrote: > >>>>>>>> Hi Markus, > >>>>>>>> > >>>>>>>> flambda needs to be enabled explicitly at configure time with the > >>>>>>>> "-flambda" > >>>>>>>> flag. The new optimizer will then be used unconditionally, and = you > >>>>>>>> can > >>>>>>>> tweak it using command-line parameters passed to ocamlopt (see > >>>>>>>> "ocamlopt > >>>>>>>> -h"). > >>>>>>>> > >>>>>>>> > >>>>>>>> Alain > >>>>>>>> > >>>>>>>> > >>>>>>>> On 08/03/2016 23:10, Markus Mottl wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I'm trying out OCaml 4.03.0+beta1 right now and wanted to test > >>>>>>>>> Flambda > >>>>>>>>> optimizations. But looking at the generated assembly, it doesn= 't > >>>>>>>>> seem > >>>>>>>>> to be doing much if anything on the simple test examples that I > >>>>>>>>> thought would benefit. > >>>>>>>>> > >>>>>>>>> To give an example of what I expected to see, lets consider this > >>>>>>>>> code: > >>>>>>>>> > >>>>>>>>> ----- > >>>>>>>>> let map_pair f (x, y) =3D f x, f y > >>>>>>>>> > >>>>>>>>> let succ x =3D x + 1 > >>>>>>>>> let map_pair_succ1 pair =3D map_pair succ pair > >>>>>>>>> let map_pair_succ2 (x, y) =3D succ x, succ y > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>> I would have thought that the "succ" function would be inlined = in > >>>>>>>>> "map_pair_succ1" as the compiler would do for "map_pair_succ2". > >>>>>>>>> But the generated code looks like this: > >>>>>>>>> > >>>>>>>>> ----- > >>>>>>>>> L101: > >>>>>>>>> movq %rax, %rdi > >>>>>>>>> movq %rdi, 8(%rsp) > >>>>>>>>> movq %rbx, (%rsp) > >>>>>>>>> movq 8(%rbx), %rax > >>>>>>>>> movq (%rdi), %rsi > >>>>>>>>> movq %rdi, %rbx > >>>>>>>>> call *%rsi > >>>>>>>>> L102: > >>>>>>>>> movq %rax, 16(%rsp) > >>>>>>>>> movq (%rsp), %rax > >>>>>>>>> movq (%rax), %rax > >>>>>>>>> movq 8(%rsp), %rbx > >>>>>>>>> movq (%rbx), %rdi > >>>>>>>>> call *%rdi > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>> Is Flambda supposed to work out of the box with the current bet= a? > >>>>>>>>> What flags or annotations should I use for testing? Any showca= se > >>>>>>>>> examples I should try out that are expected to be improved? > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Markus > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Markus Mottl http://www.ocaml.info markus.mottl@gma= il.com > >>>>>>> > >>>>>>> -- > >>>>>>> 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 > >>>>> > >>>>> > >>>>> -- > >>>>> Markus Mottl http://www.ocaml.info markus.mottl@gmail= .com > >>>>> > >>>>> -- > >>>>> 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 > >>>> > >>> > >>> > >>> -- > >>> Markus Mottl http://www.ocaml.info markus.mottl@gmail.c= om > > > > >=20 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-k+4htR0+VPmhgYDT/cbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJW4fqLAAoJEAaM4b9ZLB5TTNYH/ijGxlucMReAFv/qZ7Z4+TuW 7Mc/PuqLMZPd387IbUtyvVV6J8oPfjV36hWAsm42QrCbrVAGCMzYy1oWlglWm9Tm hbFXNPYCMxi5L1e7j0GqK3z2A0UX9zoiNvcqJrcFPQWGESy6e3N7UuX8VSVorNX1 pjeL/oCaBNvufm/ZHL8CKGKXO6MyfjSA65suq5h/zPfD8A8OYpqSxpD30w2qX11h R2zH9MPWFihRfVpOVsFNMPcxQ6Xf7NC+yIxjmYGJ/RCpht8B7FDMYm4C/zUoQ1Tg 5bCbEwscWtXJdap4lX/ucVivg+Bgulgj3c2WvmRvSL2zns+nzrKOTqUDDG/DCjA= =sk8c -----END PGP SIGNATURE----- --=-k+4htR0+VPmhgYDT/cbD--