linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:33:15 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0706241824080.10397@asgard.lang.hm> (raw)
In-Reply-To: <1182734240.26621.2.camel@laptopd505.fenrus.org>

On Sun, 24 Jun 2007, Arjan van de Ven wrote:

> On Sun, 2007-06-24 at 18:08 -0700, david@lang.hm wrote:
>>>
>>> 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?
>
> that isn't so easy. Anything which doesn't have a performance tradeoff
> is in -O2 already. So every single thing in -Os costs you performance on
> a micro level.

this has not been true in the past (assuming that it's true today)

ok, if you look at a micro-enough level this may be true, but completely 
ignoring things like download times, the optimizations almost always boil 
down to trying to avoid jumps, loops, and decision logic at the expense of 
space.

however recent cpu's are significantly better as handling jumps and loops, 
and the cost of cache misses is significantly worse.

is the list of what's included in -O2 vs -Os different for different 
CPU's? what about within a single family of processors? (even in the x86 
family the costs of jumps, loops, and cache misses varies drasticly)

my understanding was that the optimizations for O2 were pretty fixed.

> The translation to macro level depends greatly on how things are used
> (you even have to factor in download times etc)... so that is a fair
> question to leave up to the user... which is what there is today.

ignore things like download time for the moment. it's not significant to 
most people as they don't download things that often, and when they do 
they are almost always downloading lots of stuff they don't need (drivers 
for example)

users are trying to get better performance 90+% of the time when they 
select -Os. That's why it got moved out of CONFIG_EMBEDDED.

David Lang


  reply	other threads:[~2007-06-25  1:33 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
2007-06-25  1:17                       ` Arjan van de Ven
2007-06-25  1:33                         ` david [this message]
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.0706241824080.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).