linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Willy Tarreau <w@1wt.eu>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
	linux-kernel@vger.kernel.org,
	Arjan van de Ven <arjan@infradead.org>,
	Adrian Bunk <bunk@stusta.de>,
	david@lang.hm, Oleg Verych <olecom@flower.upol.cz>,
	rae l <crquan@gmail.com>
Subject: Re: -Os versus -O2
Date: Mon, 25 Jun 2007 10:41:22 +0200	[thread overview]
Message-ID: <0b1029a9b2de1679f6361557ad703c03@kernel.crashing.org> (raw)
In-Reply-To: <20070625081905.GA15209@1wt.eu>

>>> In my experience, -Os produced faster code on gcc-2.95 than -O2 or 
>>> -O3.
>>
>> On what CPU?  The effect of different optimisations varies
>> hugely between different CPUs (and architectures).
>
> x86

That's not a CPU, that's an architecture.  I hope you
understand there are very big differences between different
members of the x86 family and you don't compare 2.95 on a
Pentium class CPU to 3.x on an Opteron or 4.x on a Pentium4
or something like that.

>>> With gcc-3.3, -Os show roughly the same performance as -O2 for me on
>>> various programs. However, with gcc-3.4, I noticed a slow down with
>>> -Os. And with gcc-4, using -Os optimizes only for size, even if the
>>> output code is slow as hell. I've had programs whose speed dropped
>>> by 70% using -Os on gcc-4.
>>
>> Well you better report those!  <http://gcc.gnu.org/bugzilla>
>
> No, -Os is for size only :
>
>        -Os Optimize for size.  -Os enables all -O2 optimizations
>            that do not typically increase code size.  It also
>            performs further optimizations designed to reduce code
>            size.

That is not "for size only".  Please read again.

A 70% speed decrease is something that should be at least
investigated, even if then perhaps it is decided GCC already
does the "right thing".

> So it is expected that speed can be reduced using -Os. I won't report
> a thing which is already documented !

A few percent points slower is expected, 20% would be
explainable, but 70%?

-O2 and -Os are supposed to differ in _minor_ ways.  Such
a huge performance drop is unexpected.  If you file the PR,
feel free to blame me for reporting it at all.

>>> But in some situtations, it's desirable to have the smallest possible
>>> kernel whatever its performance. This goes for installation CDs for
>>> instance.
>>
>> There are much better ways to achieve that.
>
> Optimizing is not a matter of choosing *one* way, but cumulating
> everything you have.

Yes of course.  I'm just saying -Os is a pretty minor step
in the overall making-things-smaller game.  Leaving out XFS
helps a whole megabyte on my default target, for example.

> For instance, on a smart boot loader, I have
> a kernel which is about 300 kB, or 700 kB with the initramfs. Among
> the tricks I used :
>   - -Os
>   - -march=i386
>   - align everything to 0
>   - replace gzip with p7zip
>
> Even if each of them reduces overall size by 5%, the net result is
> 0.95^4 = 0.81 = 19% gain, for the same set of features. This is
> something to consider.

Sure.  I don't think making -Os mean "as small as possible
in all cases" (or, rather, introducing a new option for that)
would help terribly much over the current -Os meaning -- a
few percent at most.  That's not to say that no such optimisations
are added anymore, but mostly they turn out not to decrease
speed at all and so are enabled at any -O level :-)


Segher


  reply	other threads:[~2007-06-25  8:41 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
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 [this message]
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=0b1029a9b2de1679f6361557ad703c03@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=arjan@infradead.org \
    --cc=bcrl@kvack.org \
    --cc=bunk@stusta.de \
    --cc=crquan@gmail.com \
    --cc=david@lang.hm \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olecom@flower.upol.cz \
    --cc=w@1wt.eu \
    /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).