From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id EC3FA5582 for ; Tue, 26 Jul 2016 18:44:22 +0200 (CEST) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 7B457C8; Tue, 26 Jul 2016 09:44:22 -0700 (PDT) Date: Tue, 26 Jul 2016 09:44:22 -0700 From: Matthew Hall To: Luca Boccassi Cc: "dev@dpdk.org" , "christian.ehrhardt@canonical.com" , "cjcollier@linuxfoundation.org" , "ricardo.salveti@linaro.org" Message-ID: <20160726164422.GB1484@mhcomputing.net> References: <1469544793.4240.24.camel@brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1469544793.4240.24.camel@brocade.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] Compiler hardening flags for libraries and performance implications X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 16:44:23 -0000 On Tue, Jul 26, 2016 at 02:53:13PM +0000, Luca Boccassi wrote: > While working on uploading DPDK to Ubuntu and Debian, we were wondering > if anyone had any thoughts/opinions on enabling compiler hardening flags > for the DPDK libraries and the possible performance implications. Most of the C profilers, both VTune and Perf based tools, have not given me that much helpful data. They make it very hard to go from slow functions down to actual slow lines of code causing performance issues that I should fix. So I would love to see a MUCH better DPDK tuning guide, because the current one is really generic and gives no useful advice beyond what any programmer has already heard many times that doesn't really add much value. This issue aside, in general I found that all the bounds-checking stuff, various FORTIFY_SOURCE items, and other supposedly "helpful" code security functions were chewing up a lot of CPU resources in the profiling output, and obscuring the actual slow parts of code being executed in the profiling runs. This stuff was making it difficult for me to optimize my code effectively, because they replace readable things which exist in real files and have symbols with wrappers that don't have working symbols and such. > Any opinions? Would anyone have reservations if we enabled all of these > in the packages that will be distributed in Ubuntu and Debian? Based on the bad stuff that happened to me, I had to disable all these things to get useful results and start making the code run faster. But it would be nice to have some better advice on profilers and do some actual measurements before-and-after to see if my experiences are repeatable. Matthew.