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 45BA7800AD for ; Thu, 22 Dec 2016 18:23:31 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=pierre.chambart@ocamlpro.com; spf=None smtp.mailfrom=pierre.chambart@ocamlpro.com; spf=Pass smtp.helo=postmaster@redisdead.crans.org Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of pierre.chambart@ocamlpro.com) identity=pra; client-ip=138.231.136.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="pierre.chambart@ocamlpro.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of pierre.chambart@ocamlpro.com) identity=mailfrom; client-ip=138.231.136.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="pierre.chambart@ocamlpro.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.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=mail3-smtp-sop.national.inria.fr; envelope-from="pierre.chambart@ocamlpro.com"; x-sender="postmaster@redisdead.crans.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" IronPort-PHdr: =?us-ascii?q?9a23=3AyWhqjRHgC1UW1H3P4B3spZ1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ7zosywAkXT6L1XgUPTWs2DsrQf2rGQ4/yrADRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLd8IRmsrgjcucYajZZ+Jqot1xDEvmZGd+?= =?us-ascii?q?NKyG1yOFmdhQz85sC+/J5i9yRfpfcs/NNeXKv5Yqo1U6VWACwpPG4p6sLrswLD?= =?us-ascii?q?TRaU6XsHTmoWiBtIDBPb4xz8Q5z8rzH1tut52CmdIM32UbU5Uims4qt3VBPljj?= =?us-ascii?q?oMOiUn+2/LlMN/kKNboAqgpxNhxY7UfJqVP+d6cq/EYN8WWXZNUsNXWidcAI2z?= =?us-ascii?q?cpEPAvIcM+hGoYnzp1wOoxiwCwaiC+zgyCNHiHDt0K0myuQsCx3K0BAuEt8Mtn?= =?us-ascii?q?nfsdX7NL0VUeCw1KTG1zTDYO1M2Tfn9ofDbw4sofGWUrJ1asXe01MvFx/YhViX?= =?us-ascii?q?sYzlPi2a1v4Xs2eF9eZvSeKvhHQiqw5quDev3Nssh5LOho0J0F/E8CF5wJ4vJd?= =?us-ascii?q?2/UkJ0fdmkEJ5JuiycKoB4QdsiTnl1tCs0ybAKo4C3cSYXxJg92hLSZf2Kf5KG?= =?us-ascii?q?7x/nTOqdPDl1iX1/dL6ihxu/81KsxvPiWsWuzVpHrilIn9/RvX4XzRPT8NKISv?= =?us-ascii?q?5l80ehxzmP0wfT5/leIU8qiKXbKoUhzaMumZUJrEvPBDP5mF/sg6+QbUUo4O+o?= =?us-ascii?q?6/7oYrn+p5+cMZF7ih3mP6gzlMGyAv40PhYAUmSG4+iwybPu8EzjTLhEivA6iq?= =?us-ascii?q?zZv4rbJcQfqK65GQhV0oM75hanDjepzs4YnWMZI15fZB2Hj5LmO1TVL//iF/e/?= =?us-ascii?q?n0+hkDB3yP/cO73hBo3NLmLEkLv7Ybl97EtcxBIpzd9D/5JUFq0BIPXrV0Dtrt?= =?us-ascii?q?PYCxs5PxWww+bmE9V9ypgTWXmPA6+cKKPdq0WE5uMpI+mWZY8aoizxK/Y/562m?= =?us-ascii?q?sXhssFsUfK/h84EWc3u4VqBvJ0yYZzzimNYaGmciugcuTeLrzlaFVGgASWy1Wv?= =?us-ascii?q?cE5zwhEo/uJofKQ4qkmqDJiD+6E4dMayZNClmJG37ya62DUP4JbDqIJYlqlTlS?= =?us-ascii?q?BuvpcJMoyRz77Fyy8LFgNOeBv3RA7Z8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgFgCYClxY/yeI54peGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgwoBAQEBAR+BDCCkXJcehiICgWxDEAEBAQE?= =?us-ascii?q?BAQEBAQEBYSiCMxoBghsBBSMETQUQCxgCAiYCAlcGDQgBAYhpBaoqgWw8iwABA?= =?us-ascii?q?QEHAQEBAQEjgQuFPYICgmGES4MEgl0FmnmBeop/hk6IFoYvjiaEDzYgAYFYhWK?= =?us-ascii?q?JWgEBAQ?= X-IPAS-Result: =?us-ascii?q?A0DgFgCYClxY/yeI54peGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgwoBAQEBAR+BDCCkXJcehiICgWxDEAEBAQEBAQEBAQEBYSiCM?= =?us-ascii?q?xoBghsBBSMETQUQCxgCAiYCAlcGDQgBAYhpBaoqgWw8iwABAQEHAQEBAQEjgQu?= =?us-ascii?q?FPYICgmGES4MEgl0FmnmBeop/hk6IFoYvjiaEDzYgAYFYhWKJWgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,389,1477954800"; d="scan'208";a="205557488" Received: from redisdead.crans.org ([138.231.136.39]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 18:23:30 +0100 Received: from [134.157.22.158] (unknown [134.157.22.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by redisdead.crans.org (Postfix) with ESMTPSA id 30FAAB85; Thu, 22 Dec 2016 18:23:28 +0100 (CET) To: Alain Frisch References: <7bc766a2-d460-524b-35ca-89609a34b719@tu-berlin.de> <1482148297.4629.19.camel@gerd-stolpmann.de> <0F7D3B1B3C4B894D824F5B822E3E5A172CFB9581@IRSMSX102.ger.corp.intel.com> <1482165686.4629.28.camel@gerd-stolpmann.de> <1506c421-618a-28d4-9a7b-7ba49baf47fa@lexifi.com> <45f9251b-c362-ac9f-fa71-07ab42087c90@lexifi.com> <1482337872.4629.108.camel@gerd-stolpmann.de> Cc: "caml-list@inria.fr" From: Pierre Chambart Organization: OcamlPro Message-ID: <74a66a9f-df8b-32c4-482f-71c0df91293c@ocamlpro.com> Date: Thu, 22 Dec 2016 18:23:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Validation-by: pierre.chambart@ocamlpro.com Subject: Re: [Caml-list] Closing the performance gap to C Le 21/12/2016 =C3=A0 18:43, Alain Frisch a =C3=A9crit : > On 21/12/2016 17:56, Mark Shinwell wrote: >> I agree with Gabriel, but, we are planning substantial work within >> Flambda during the coming year to implement unboxing transformations >> therein. I do think we should spend a little time, before diving into >> this particular issue, convincing ourselves that these two tracks of >> work are going to be complementary rather than conflicting. > > Dealing with boxing/unboxing in flambda rather than keeping it at the > cmm level certainly seems the way to go in the context of the flambda > pipeline. This will probably need to touch the definition of clambda > (to bring it closer to cmm) and thus cmmgen. Do you believe this is > compatible with continuing sharing clambda and cmmgen between the > flambda and non-flambda pipeline? At some point, it might be more > natural, or just required, to compile flambda directly to cmm without > going through clambda. What do you think? > > If the flambda pipeline targets cmm directly without going through > clambda/cmmgen, the approach discussed here (for the non-flambda case) > should not interact too much with the flambda version. As far as I > can tell, they would mostly share the plumbing required to pass more > info from typedtree to lambda. > > > Alain > The machinery to do that correctly could be certainly be shared I think. The way I see it, is change the semantics of the float related primitives at the clambda and flambda level. This should represent explicitly unboxed float manipulation. The Closure/Closure_conversion (or Flambda_to_clambda for a first patch that does not change how flambda works) passes would rewrite them to be enclosed by new box/unbox primitives. For instance in Cmmgen this would look like: | Pmulfloat -> Cop(Cmulf, [transl env arg1; transl env arg2], dbg) | Pboxfloat -> box_float dbg (transl env arg) | Punboxfloat -> transl_unbox_float dbg env arg Then on functions and direct calls at clambda level, like in my old patch, annotate the calling convention. This should be sufficient for doing what was done in that patch without degrading anything and still allowing this to be implemented separately in flambda. Of course the Typedtree to lambda type annotation propagation can be shared without any problem. Updating the patch for that will be a be tedious, but simple. If you don't like the idea of having primitives that does not mean exactly the same thing at the different stages of the compiler, introducing a new unboxed version of each float primitives is also possible (with its use forbidden in lambda). I would like at some point to have a different type for lambda primitives and clambda primitives. It might be the right time to do that. Also, there was a problem with the approach of that old patch that bothered me. The function argument unboxing decision had to guess whether an argument was going to be used boxed or not. If the guess is wrong you might end up allocating more than without unboxing. Having the annotation there explicitly allow to do the unboxing earlier and rely on the annotation for the decision. Notice that the transformation was not completely local as it had to propagate across functions which argument might be used unboxed. In particular, recursive functions made it a bit complex. This was the job of the added Specialisation module. --=20 Pierre