From: Tim Mattox <tmattox@gmail.com>
To: Willy Tarreau <willy@w.ods.org>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
Harald Welte <laforge@netfilter.org>,
netdev@vger.kernel.org, netfilter-devel@lists.netfilter.org,
linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH 2/3] netfilter : 3 patches to boost ip_tables performance
Date: Fri, 23 Sep 2005 10:00:27 -0400 [thread overview]
Message-ID: <ea86ce2205092307003e8c2d8c@mail.gmail.com> (raw)
In-Reply-To: <20050923040234.GC595@alpha.home.local>
AFAIK, the usual reason gcc can generate better code when you write
bool = complex conditional
if (bool) ...
is because of C's short-circuit conditional evaluation rules for || and &&. By
moving the complex expression to an assignment statement, you are telling
gcc that it is okay and safe to evaluate every part of the expression.
If gcc was smart about being able to prove that all parts of the complex
expression where safe (no possibly null pointer references) and had no
side effects, then it could generate the same code with
if (complex conditional) ...
However, there are many situations where even a magical compiler
couldn't prove that there were no possible side effects, etc., and would
have to generate multiple conditional branches to properly meet the
short-circuit conditional evaluation rules for && and ||.
However, in the specific cases in this thread using FWINV without
|| and && operators, an optimizing compiler "should" be smart enough
to generate more linear code for today's heavily pipelined CPUs.
For now, I guess it's still the duty of the programmer to use coding
style to force the compiler to generate more linear machine code.
On 9/23/05, Willy Tarreau <willy@w.ods.org> wrote:
> On Thu, Sep 22, 2005 at 03:05:50PM +0200, Eric Dumazet wrote:
> (...)
> > It was necessary to get the best code with gcc-3.4.4 on i386 and
> > gcc-4.0.1 on x86_64
> >
> > For example :
> >
> > bool1 = FWINV(ret != 0, IPT_INV_VIA_OUT);
> > if (bool1) {
> >
> > gives a better code than :
> >
> > if (FWINV(ret != 0, IPT_INV_VIA_OUT)) {
> >
> > (one less conditional branch)
> >
> > Dont ask me why, it is shocking but true :(
>
> I also noticed many times that gcc's optimization of "if (complex condition)"
> is rather poor and it's often better to put it in a variable before. I even
> remember that if you use an intermediate variable, it can often generate a
> CMOV instruction on processors which support it, while it produces cond tests
> and jumps without the variable. Generally speaking, if you want fast code,
> you have to write it as a long sequence of small instructions, just as if
> you were writing assembly. As you said, shocking but true.
>
> BTW, cheers for your optimizations !
>
> Regards,
> Willy
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Tim Mattox - tmattox@gmail.com
http://homepage.mac.com/tmattox/
I'm a bright... http://www.the-brights.net/
next prev parent reply other threads:[~2005-09-23 14:00 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 17:09 [PATCH, netfilter] NUMA aware ipv4/netfilter/ip_tables.c Eric dumazet
2005-09-19 17:20 ` Eric Dumazet
2005-09-19 17:48 ` Andi Kleen
2005-09-19 19:09 ` Eric Dumazet
2005-09-20 9:47 ` Eric Dumazet
2005-09-20 16:30 ` Andi Kleen
2005-09-20 17:02 ` Eric Dumazet
2005-09-20 21:45 ` [PATCH] Adds sys_set_mempolicy() in include/linux/syscalls.h , " Eric Dumazet
2005-09-20 21:46 ` [PATCH] Adds sys_set_mempolicy() in include/linux/syscalls.h Eric Dumazet
2005-09-21 21:24 ` [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-21 22:43 ` Christoph Lameter
2005-09-22 0:34 ` David S. Miller
2005-09-22 1:44 ` Christoph Lameter
2005-09-22 12:11 ` Eric Dumazet
2005-09-22 12:49 ` Christoph Hellwig
2005-09-22 12:54 ` Andi Kleen
2005-09-22 12:58 ` Christoph Hellwig
2005-09-22 13:05 ` Andi Kleen
2005-09-22 15:37 ` Christoph Lameter
2005-09-22 15:50 ` Eric Dumazet
2005-09-22 15:55 ` Christoph Lameter
2005-09-23 17:11 ` Harald Welte
2005-09-23 17:44 ` Christoph Lameter
2005-09-23 18:04 ` Dave Hansen
2005-09-23 17:47 ` Eric Dumazet
2005-09-23 18:00 ` Kyle Moffett
2005-09-22 4:18 ` James Morris
2005-09-22 5:07 ` Eric Dumazet
2005-09-22 13:03 ` Andi Kleen
2005-09-22 13:30 ` Eric Dumazet
2005-09-23 17:09 ` Harald Welte
2005-09-27 16:23 ` Andi Kleen
2005-09-28 0:25 ` Henrik Nordstrom
2005-09-28 8:32 ` Harald Welte
2005-09-28 8:37 ` Andi Kleen
2005-10-04 17:01 ` Patrick McHardy
2005-10-05 16:53 ` Andi Kleen
2005-10-07 2:38 ` Harald Welte
2005-10-06 17:59 ` Andi Kleen
2005-10-07 17:08 ` Patrick McHardy
2005-10-07 17:21 ` Andi Kleen
2005-10-07 17:50 ` Patrick McHardy
2005-09-28 10:34 ` Henrik Nordstrom
2005-11-25 11:23 ` [PATCH] netfilter : zap get_cpu()/put_cpu() calls from ip_tables Eric Dumazet
2005-11-25 11:28 ` [PATCH (resent with the attachment !)] " Eric Dumazet
2005-11-25 18:20 ` Patrick McHardy
2005-09-21 21:29 ` [PATCH 1/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-22 12:57 ` Harald Welte
2005-09-22 13:17 ` Eric Dumazet
2005-09-21 21:32 ` [PATCH 2/3] " Eric Dumazet
2005-09-22 12:48 ` Harald Welte
2005-09-22 13:05 ` Eric Dumazet
2005-09-23 4:02 ` Willy Tarreau
2005-09-23 5:14 ` Eric Dumazet
2005-09-23 11:33 ` Willy Tarreau
2005-09-23 14:00 ` Tim Mattox [this message]
2005-09-21 21:37 ` [PATCH 3/3] " Eric Dumazet
2005-09-22 12:50 ` Harald Welte
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=ea86ce2205092307003e8c2d8c@mail.gmail.com \
--to=tmattox@gmail.com \
--cc=ak@suse.de \
--cc=dada1@cosmosbay.com \
--cc=laforge@netfilter.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=willy@w.ods.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).