From: Matthew Hall <mhall@mhcomputing.net>
To: Luca Boccassi <lboccass@Brocade.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"christian.ehrhardt@canonical.com"
<christian.ehrhardt@canonical.com>,
"cjcollier@linuxfoundation.org" <cjcollier@linuxfoundation.org>,
"ricardo.salveti@linaro.org" <ricardo.salveti@linaro.org>
Subject: Re: [dpdk-dev] Compiler hardening flags for libraries and performance implications
Date: Tue, 26 Jul 2016 09:44:22 -0700 [thread overview]
Message-ID: <20160726164422.GB1484@mhcomputing.net> (raw)
In-Reply-To: <1469544793.4240.24.camel@brocade.com>
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.
next prev parent reply other threads:[~2016-07-26 16:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 14:53 Luca Boccassi
2016-07-26 16:44 ` Matthew Hall [this message]
2016-07-27 12:58 ` Mcnamara, John
2016-07-27 15:46 ` Matthew Hall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160726164422.GB1484@mhcomputing.net \
--to=mhall@mhcomputing.net \
--cc=christian.ehrhardt@canonical.com \
--cc=cjcollier@linuxfoundation.org \
--cc=dev@dpdk.org \
--cc=lboccass@Brocade.com \
--cc=ricardo.salveti@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).