All of lore.kernel.org
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: gcc -O2 vs gcc -Os performance
Date: Thu, 6 Feb 2003 22:12:51 +0000 (UTC)	[thread overview]
Message-ID: <b1uml3$2af$1@penguin.transmeta.com> (raw)
In-Reply-To: 263740000.1044563891@[10.10.2.4]

In article <263740000.1044563891@[10.10.2.4]>,
Martin J. Bligh <mbligh@aracnet.com> wrote:
>>> All done with gcc-2.95.4 (Debian Woody). These machines (16x NUMA-Q) have 
>>> 700MHz P3 Xeons with 2Mb L2 cache ... -Os might fare better on celeron 
>>> with a puny cache if someone wants to try that out
>> 
>> gcc 3.2 is a lot smarter about -Os and it makes a very big size
>> difference according to the numbers the from the ACPI guys.
>> 
>> Im not sure testing with a gcc from the last millenium is useful 8)
>
>Still no use.
>/me throws gcc-3.2 in the trash can.
>
>2901299 vmlinux.O2
>2667827 vmlinux.Os

Well, Os is certainly smaller.  One thing to look out for is that
microbenchmarks for kernels are usually the _worst_ things to test with
Os.

That's since a large part of the premise of the -Os speed advantage is
that it is better for icache (usually not an issue for microbenchmarks)
and that it is better for load/startup times (generally not a huge issue
for kernels, since the real startup costs of kernels tend to be entirely
elsewhere).

So I suspect -Os tends to be more appropriate for user-mode code, and
especially code with low repeat rates.  Possibly the "low repeat rate"
thing ends up being true of certain kernel subsystems too.

Think of it this way: if you win 10% in size, you're likely to map and
load 10% less code pages at run-time. Which is not a big issue for
traditional data-centric loads, but can be a _huge_ deal for things like
GUI programs etc where there is often more code than data.

			Linus

  parent reply	other threads:[~2003-02-06 22:06 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-03 23:05 gcc 2.95 vs 3.21 performance Martin J. Bligh
2003-02-03 23:22 ` [Lse-tech] " Andi Kleen
2003-02-03 23:31 ` Richard B. Johnson
2003-02-04  0:43   ` J.A. Magallon
2003-02-04 13:42     ` Richard B. Johnson
2003-02-04 14:20       ` John Bradford
2003-02-04  6:54   ` Denis Vlasenko
2003-02-04  7:13     ` Martin J. Bligh
2003-02-04 12:25       ` Adrian Bunk
2003-02-04 15:51         ` Martin J. Bligh
2003-02-04 16:27           ` [Lse-tech] " Martin J. Bligh
2003-02-04 17:40             ` Patrick Mansfield
2003-02-04 17:55               ` Martin J. Bligh
2003-02-04  9:54     ` Bryan Andersen
2003-02-04 15:46       ` Martin J. Bligh
2003-02-04 19:09     ` Timothy D. Witham
2003-02-04 19:35       ` John Bradford
2003-02-04 19:44         ` Dave Jones
2003-02-04 20:11           ` John Bradford
2003-02-04 20:20             ` John Bradford
2003-02-04 20:45             ` Herman Oosthuysen
2003-02-04 21:44               ` Timothy D. Witham
2003-02-05  7:15               ` Denis Vlasenko
2003-02-05 10:36                 ` Andreas Schwab
2003-02-05 11:41                   ` Denis Vlasenko
2003-02-05 12:20                     ` Dave Jones
2003-02-05 13:10                     ` [Lse-tech] " Dipankar Sarma
2003-02-05 15:30                 ` Martin J. Bligh
2003-02-04 21:38         ` Linus Torvalds
2003-02-04 21:54           ` John Bradford
2003-02-04 22:11             ` Linus Torvalds
2003-02-04 23:27               ` Timothy D. Witham
2003-02-04 23:21           ` Larry McVoy
2003-02-04 23:42             ` b_adlakha
2003-02-05  0:19               ` Andy Pfiffer
2003-02-04 23:51             ` Jakob Oestergaard
2003-02-05  1:03               ` Hugo Mills
2003-02-10 22:26               ` Andrea Arcangeli
2003-02-10 23:28                 ` J.A. Magallon
2003-02-04 23:51             ` Eli Carter
2003-02-05  0:27               ` Larry McVoy
2003-02-06 20:42                 ` Paul Jakma
2003-02-05  3:03             ` Tomas Szepe
2003-02-05  6:03             ` Mark Mielke
2003-02-07 16:09           ` Pavel Machek
2003-02-04 10:57   ` Padraig
2003-02-04 13:11     ` Helge Hafting
2003-02-04 13:29       ` Jörn Engel
2003-02-04 14:05       ` P
2003-02-04 20:36         ` Herman Oosthuysen
2003-02-04 12:20 ` [Lse-tech] " Dave Jones
2003-02-04 15:50   ` Martin J. Bligh
2003-02-10 12:13     ` Momchil Velikov
2003-02-06 15:42 ` gcc -O2 vs gcc -Os performance Martin J. Bligh
2003-02-06 15:51   ` [Lse-tech] " Andi Kleen
2003-02-06 17:48   ` Alan Cox
2003-02-06 17:06     ` Martin J. Bligh
2003-02-06 20:38     ` Martin J. Bligh
2003-02-06 21:32       ` John Bradford
2003-02-06 22:12       ` Linus Torvalds [this message]
2003-02-06 22:58         ` Martin J. Bligh
2003-02-06 23:16           ` Linus Torvalds
2003-02-06 23:59             ` Martin J. Bligh
2003-02-06 23:17       ` Roger Larsson
2003-02-06 23:33         ` Martin J. Bligh

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='b1uml3$2af$1@penguin.transmeta.com' \
    --to=torvalds@transmeta.com \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.