From: david@lang.hm
To: Arjan van de Ven <arjan@infradead.org>
Cc: Adrian Bunk <bunk@stusta.de>, Benjamin LaHaise <bcrl@kvack.org>,
Oleg Verych <olecom@flower.upol.cz>, rae l <crquan@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: -Os versus -O2
Date: Sun, 24 Jun 2007 18:08:08 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0706241801320.10397@asgard.lang.hm> (raw)
In-Reply-To: <1182733127.6819.13.camel@laptopd505.fenrus.org>
On Sun, 24 Jun 2007, Arjan van de Ven wrote:
>> I wouldn't care if CONFIG_CC_OPTIMIZE_FOR_SIZE was hidden behind
>> CONFIG_EMBEDDED, but as long as it's available as a general purpose
>> option we have to consider it's performance.
>
> I think you are missing the point. You tell the kernel to
> OPTIMIZE_FOR_SIZE. *over performance*. Sure. Performance shouldn't be
> EXTREMELY pathetic, but it's not; and if it were, it's a problem with
> the gcc version you have (and if you are a distro, you can surely fix
> that)
>
>>
>> The interesting questions are:
>> Does -Os still sometimes generate faster code with gcc 4.2?
>> If yes, why?
>
> on a system level, size can help performance because you have more
> memory available for other things. It also reduces download size and
> gives you more space on the live CD....
>
> if you want to make things bigger again, please do this OUTSIDE the
> "optimize for size" option. Because that TELLS you to go for size.
then do we need a new option 'optimize for best overall performance' that
goes for size (and the corresponding wins there) most of the time, but is
ignored where it makes a huge difference?
I started useing Os several years ago, even when it was hidden in the
embedded menu becouse in many cases the smaller binary ended up being
faster.
in reality this was a flaw in gcc that on modern CPU's with the larger
difference between CPU speed and memory speed it still preferred to unroll
loops (eating more memory and blowing out the cpu cache) when it shouldn't
have.
if that has been fixed on later versions of gcc this would be a good
thing. if it hasn't (possibly in part due to gcc optimizations being
designed to be cross platform) then either the current 'go for size' or a
hybrid 'performance' option is needed.
David Lang
next prev parent reply other threads:[~2007-06-25 1:08 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-23 5:15 [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization Denis Cheng
2007-06-23 7:59 ` Oleg Verych
2007-06-23 13:13 ` Adrian Bunk
2007-06-23 13:41 ` Oleg Verych
2007-06-23 13:57 ` Adrian Bunk
2007-06-23 15:21 ` Segher Boessenkool
2007-06-24 12:58 ` rae l
2007-06-24 22:25 ` Oleg Verych
2007-06-24 22:15 ` Arjan van de Ven
2007-06-24 23:23 ` Benjamin LaHaise
2007-06-25 0:09 ` Arjan van de Ven
2007-06-25 0:12 ` Benjamin LaHaise
2007-06-25 0:23 ` Arjan van de Ven
2007-06-25 0:41 ` -Os versus -O2 Adrian Bunk
2007-06-25 0:58 ` Arjan van de Ven
2007-06-25 1:08 ` david [this message]
2007-06-25 1:17 ` Arjan van de Ven
2007-06-25 1:33 ` david
2007-06-25 1:41 ` Rene Herman
2007-06-25 5:04 ` Willy Tarreau
2007-06-25 7:08 ` Segher Boessenkool
2007-06-25 7:15 ` david
2007-06-25 7:41 ` Segher Boessenkool
2007-06-25 8:19 ` Willy Tarreau
2007-06-25 8:41 ` Segher Boessenkool
2007-06-25 7:03 ` Segher Boessenkool
2007-06-25 7:13 ` david
2007-06-25 7:35 ` Segher Boessenkool
2007-06-25 1:33 ` Adrian Bunk
2007-06-25 1:23 ` Rene Herman
2007-06-25 1:31 ` Rene Herman
2007-06-25 1:34 ` Jeff Garzik
2007-06-25 1:46 ` Adrian Bunk
2007-06-25 2:19 ` david
2007-06-24 23:33 ` memset() with zeroes (Re: [PATCH] trivial: the memset operation on a automatic array variable should be optimized out by data initialization) Oleg Verych
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=Pine.LNX.4.64.0706241801320.10397@asgard.lang.hm \
--to=david@lang.hm \
--cc=arjan@infradead.org \
--cc=bcrl@kvack.org \
--cc=bunk@stusta.de \
--cc=crquan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olecom@flower.upol.cz \
/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).