From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6FE04A0613 for ; Mon, 23 Sep 2019 12:17:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 233A41BE8E; Mon, 23 Sep 2019 12:16:59 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 9CDF41BE8B for ; Mon, 23 Sep 2019 12:16:57 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1B85E40019 for ; Mon, 23 Sep 2019 12:16:57 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 057C740009; Mon, 23 Sep 2019 12:16:56 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.2 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-207-236.mobileonline.telia.com [90.232.207.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 523F640007; Mon, 23 Sep 2019 12:16:50 +0200 (CEST) To: Ray Kinsella , Thomas Monjalon Cc: Bruce Richardson , Andrzej Ostruszka , dev@dpdk.org, Aaron Conole , Michael Santana , John McNamara , Marko Kovacevic , David Hunt , Vladimir Medvedkin , Robert Sanford , Erik Gabriel Carrillo , stephen@networkplumber.org, Andrzej Ostruszka References: <20190917075754.8310-1-amo@semihalf.com> <20190919151624.GA1999@bricha3-MOBL.ger.corp.intel.com> <1873473.QF300kEeir@xps> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <0c4cd51f-5b65-501c-b18d-068d30b8bfc6@ericsson.com> Date: Mon, 23 Sep 2019 12:16:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [PATCH v2 01/10] build: add an option to enable LTO build X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 2019-09-23 11:36, Ray Kinsella wrote: > > > On 23/09/2019 08:23, Thomas Monjalon wrote: >> 20/09/2019 09:38, Ray Kinsella: >>> >>> On 19/09/2019 16:16, Bruce Richardson wrote: >>>> On Thu, Sep 19, 2019 at 02:28:04PM +0100, Ray Kinsella wrote: >>>>> >>>>> >>>>> On 19/09/2019 13:35, Andrzej Ostruszka wrote: >>>>>> On 9/18/19 3:32 PM, Ray Kinsella wrote: >>>>> ...> >>>>>> Compilation time is much longer. In a normal hack|fix/compile/repeat >>>>>> cycle with "compile" part being simple "make" the link time might be a >>>>>> bit annoying. So I imagine keeping LTO off for the most part of the dev >>>>>> cycle and then at the end when doing release/cleanup turn LTO on - to >>>>>> either get release build ready or to get some set of warnings that you >>>>>> address before yet another attempt to release build. >>>>> >>>>> Well look, I would say a few things. >>>>> >>>>> 1. I see build times going down dramatically with Meson/Ninja in any case. >>>> >>>> In the general case yes, but mainly it helps if you have a large number of >>>> cores. For anyone building in a CI with only a couple of cores, meson+ninja >>>> isn't going to help much. >>>> >>>> /Bruce >>>> >>> >>> Very true, and I completely acknowledge that LTO adds compilation time. >>> I would just like to see it in or out, not another build time option. >> >> Please can we get some numbers to understand how longer it is? >> > > I will note here, that it will always be a function of the number of > object files involved. We should measure it now to understand ... > > On my system the non-LTO from-scratch build takes about one minute. With LTO enabled, it takes about five minutes. In addition, it makes our application *run* slower as well. This reinforces past experience I have with LTO - it's more cool than useful, unless you care much about the resulting code size.