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 B103E7F027 for ; Thu, 10 Mar 2016 08:20:24 +0100 (CET) IronPort-PHdr: 9a23:SaLNKBconx8K8leVDbOnUYRPlGMj4u6mDksu8pMizoh2WeGdxc+6YB7h7PlgxGXEQZ/co6odzbGG7OawBidZuM/JmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbvipNuDPE4R3WP1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHj20+2AEX24Kvh1NCgnDpFGmD9ai+hf94890wiqHJoXTSqwoXXz26q5xSwLzziIAKyI92G7Sg810yqlcpUTyiQZ4xtvxaZuWfMF+f6XCcNceDT5ERcZQUTNMBoeUbYIJAvEdJ+tVs8/2oF5Y/kj2PhWlGO66kmwAvXTxx6Bvlrl4HA== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=mshinwell@janestreet.com; spf=Pass smtp.mailfrom=mshinwell@janestreet.com; spf=None smtp.helo=postmaster@mxout1.mail.janestreet.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mshinwell@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="mshinwell@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of mshinwell@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="mshinwell@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C9AABiH+FWjnDIaSZehA1tBqockEOBbSGFbgKBMQc5EwEBAQEBAQEBEAEBAQEHFglQgi2CFQEBBBIRHQEBExkLAQ8LCw0CAgkdAgIhARIBBQEKEgYTEhCHbQMSAwufaoExPjGKT2eEQQEEhgwDCoRFAQEBAQEBAQEBAQEBAQEBAQEBAREGCnKFHIRCgj2EfYE6hiMMkRKFZYYZgXWBZEuHIIUvhxiGDhEegQ8iA4IzHoFQaolTAQEB X-IPAS-Result: A0C9AABiH+FWjnDIaSZehA1tBqockEOBbSGFbgKBMQc5EwEBAQEBAQEBEAEBAQEHFglQgi2CFQEBBBIRHQEBExkLAQ8LCw0CAgkdAgIhARIBBQEKEgYTEhCHbQMSAwufaoExPjGKT2eEQQEEhgwDCoRFAQEBAQEBAQEBAQEBAQEBAQEBAREGCnKFHIRCgj2EfYE6hiMMkRKFZYYZgXWBZEuHIIUvhxiGDhEegQ8iA4IzHoFQaolTAQEB X-IronPort-AV: E=Sophos;i="5.24,314,1454972400"; d="scan'208";a="206947189" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2016 08:20:23 +0100 Received: from tot-qpr-mailcore1.delacy.com ([172.27.56.68] helo=tot-qpr-mailcore1) by mxout1.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1adutR-0004fQ-JI for caml-list@inria.fr; Thu, 10 Mar 2016 02:20:21 -0500 X-JS-Flow: external Received: by tot-qpr-mailcore1 with JS-mailcore (0.1) (envelope-from ) id BW4SA1-AAABz2-Q-; 2016-03-10 02:20:21.544260-05:00 Received: from mail-oi0-f47.google.com ([209.85.218.47]) by mxgoog2.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1adutR-0008BI-B4 for caml-list@inria.fr; Thu, 10 Mar 2016 02:20:21 -0500 Received: by mail-oi0-f47.google.com with SMTP id r187so54595447oih.3 for ; Wed, 09 Mar 2016 23:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6016G+03RoBcTizx+JNo6Vn3zDgFm1ZNUyq0rAwHrSs=; b=RQE0lkADcDAnQXIGKktxadwKNEZhHIt5Gu/UThUCafvXHPBe2bcx2u5MXQAs9LE/JM 4gRw5XBVJ6KjdzSWCQW/Faz+ofGRSFFB/fI23G7SxDJJPaQBgoxGlHA+9hrLp4u7xNXM NPm68DHBsd29cEyC2lFPnNmOFbi5WhYz8+n7Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6016G+03RoBcTizx+JNo6Vn3zDgFm1ZNUyq0rAwHrSs=; b=XU/a07qnjyAaBjXIdczyl1Jiz3JXmySEgH4/v5Ed74KuwzawO7qjL7fkVcnelGFj62 XPWn1h2AMqLZPgwcta/48EZoY+qU1t3noZ3RS4qru7mccNIlw/I3eLC0wxLV2PgtS7yI XeNM7DePP3T+xDDEQvo1Jpv4INVCY1+kwW6AKEK6qE/qsf1tElYeERCYjp3eFoRiWRfm XLAIJTfv98EhKDLjJqaAYSwi+AjEmC/B12S8FUAq9ENZinXP4NCs6YpXBVIw0dgFWKbj SUAX+VlawZ8youSYQBJPAYJhoJXFJDzR8BLgnF8zqSSlqFuXuQwcYwawRQ2nCC/2WgKQ 7qRA== X-Gm-Message-State: AD7BkJIBjOWaLME7YjFt2tpbOO1eX+nJIm1N3eaamYwvcNTryKtTkK0CERcQdk4a47TRyfBu8rU9ICpfhivSmhr9zgyR1ppi2SvNACwuH6d4RlyGjxe2dMerF+wxCVtZ5rPxLYbdVdynWrxVI879 X-Received: by 10.202.196.149 with SMTP id u143mr1058405oif.10.1457594420893; Wed, 09 Mar 2016 23:20:20 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.196.149 with SMTP id u143mr1058397oif.10.1457594420693; Wed, 09 Mar 2016 23:20:20 -0800 (PST) Received: by 10.202.216.214 with HTTP; Wed, 9 Mar 2016 23:20:20 -0800 (PST) In-Reply-To: References: <56DF57FA.9070309@lexifi.com> Date: Thu, 10 Mar 2016 07:20:20 +0000 Message-ID: From:Mark Shinwell To:Markus Mottl Cc:Yotam Barnoy , Alain Frisch , OCaml List Content-Type: text/plain; charset=UTF-8 X-JS-Processed-by: mailcore X-Validation-by: mshinwell@janestreet.com Subject: Re: [Caml-list] Status of Flambda in OCaml 4.03 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 star 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 (mainly >>> > 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 wrote: >>> >> Hi Alain, >>> >> >>> >> I see, thanks. It was a little confusing, because the command line >>> >> options for tuning flambda were still available even without Flambda >>> >> 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 one 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) = f x, f y >>> >>>> >>> >>>> let succ x = x + 1 >>> >>>> let map_pair_succ1 pair = map_pair succ pair >>> >>>> let map_pair_succ2 (x, y) = 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 beta? >>> >>>> What flags or annotations should I use for testing? Any showcase >>> >>>> examples I should try out that are expected to be improved? >>> >>>> >>> >>>> Regards, >>> >>>> Markus >>> >>>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> 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.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