mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin Eriksson" <nitrax@giron.wox.org>
To: "Jamie Lokier" <lk@tantalophile.demon.co.uk>,
	"Jeff Garzik" <jgarzik@mandrakesoft.com>
Cc: "Linus Torvalds" <torvalds@transmeta.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [ACPI] ACPI mentioned on lwn.net/kernel
Date: Sat, 26 Jan 2002 19:25:02 +0100	[thread overview]
Message-ID: <018801c1a696$c55e95a0$0201a8c0@HOMER> (raw)
In-Reply-To: <200201251550.g0PFoIPa002738@tigger.cs.uni-dortmund.de> <200201250802.32508.bodnar42@phalynx.dhs.org> <jeelkes8y5.fsf@sykes.suse.de> <a2sv2s$ge3$1@penguin.transmeta.com> <20020126034106.F5730@kushida.apsleyroad.org> <012d01c1a687$faa11120$0201a8c0@HOMER> <3C52DD96.183322F9@mandrakesoft.com> <20020126174800.D6724@kushida.apsleyroad.org>


----- Original Message -----
From: "Jamie Lokier" <lk@tantalophile.demon.co.uk>
To: "Jeff Garzik" <jgarzik@mandrakesoft.com>
Cc: "Martin Eriksson" <nitrax@giron.wox.org>; "Linus Torvalds"
<torvalds@transmeta.com>; <linux-kernel@vger.kernel.org>
Sent: Saturday, January 26, 2002 6:48 PM
Subject: Re: [ACPI] ACPI mentioned on lwn.net/kernel


> Jeff Garzik wrote:
> > > Hmm.. I tried to compile the kernel with -Os (gcc 2.96-98) and I just
got a
> > > ~1% smaller vmlinux and a ~3% smaller bzImage. Maybe the size
optimizations
> > > doesn't show on these files? Internal data structures that are much
bigger
> > > than "real" code?
> >
> > That doesn't tell us much unless you benchmark any speed
> > improvements/degradations noticed.  Hidden in that 1% may be more
> > favorable I-cache usage, better register usage... who knows.
> >
> > It would also be interesting to compile key files like kernel/sched.c or
> > mm/vmscan.c in assembly using O2 and Os, and compare the output with
> > diff -u.
>
> It'd be good to know why it's not achieving the quoted 30% space saving
> that other compilers manage for normal code, unless it's myth of course.
>

So I compiled sched.c to assembly (note that I have the rml preempt patch
there too), and the results are pretty strange:

Diff between -O2 and -Os:
http://giron.wox.org/sched.s.diff

As you can see, not much size optimizing are done from -O2.

The C file:
http://giron.wox.org/sched.c

Command line:
gcc -D__KERNEL__ -Wall -Wstrict-prototypes -Wno-trigraphs -OX \
    -fomit-frame-pointer -fno-strict-aliasing -fno-common -S sched.c

where -OX have been replaced by -O0 -O2 -O3 and -Os

The assembler files:
http://giron.wox.org/sched.s.o0
http://giron.wox.org/sched.s.o2
http://giron.wox.org/sched.s.o3
http://giron.wox.org/sched.s.os

The file created with -O0 (no optimization) is the biggest of all, even
bigger than -O3.
-O2 and -Os differ only about 1%

So either
a) -O2 does size optimization
b) -Os sucks at size optimization

_____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  MSc CSE student, department of Computing Science
|  Umeå University, Sweden



  reply	other threads:[~2002-01-26 18:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-25 15:42 Moore, Robert
2002-01-25 15:50 ` Horst von Brand
2002-01-25 16:02   ` Ryan Cumming
2002-01-25 16:15     ` Andreas Schwab
2002-01-25 20:05       ` Ryan Cumming
2002-01-26  1:00       ` Linus Torvalds
2002-01-26  3:41         ` Jamie Lokier
2002-01-26 16:39           ` Martin Eriksson
2002-01-26 16:47             ` Jeff Garzik
2002-01-26 17:48               ` Jamie Lokier
2002-01-26 18:25                 ` Martin Eriksson [this message]
2002-01-26 21:42             ` Linus Torvalds
2002-01-30  9:22               ` Andrey Panin
     [not found]                 ` <Pine.LNX.4.33.0201291412590.18804-100000@coffee.psychology.mcmaster.ca>
2002-01-30  8:00                   ` Andrey Panin
2002-01-26 17:33         ` Felix von Leitner
2002-01-26 19:40           ` Florian Weimer
2002-01-27 13:56         ` Martin Dalecki
  -- strict thread matches above, loose matches on Subject: below --
2002-01-27 23:58 Dieter Nützel
     [not found] <200201251550.g0PFoIPa002738@tigger.cs.uni-dortmund.de.suse.lists.linux.kernel>
     [not found] ` <200201250802.32508.bodnar42@phalynx.dhs.org.suse.lists.linux.kernel>
     [not found]   ` <jeelkes8y5.fsf@sykes.suse.de.suse.lists.linux.kernel>
     [not found]     ` <a2sv2s$ge3$1@penguin.transmeta.com.suse.lists.linux.kernel>
     [not found]       ` <20020126034106.F5730@kushida.apsleyroad.org.suse.lists.linux.kernel>
     [not found]         ` <012d01c1a687$faa11120$0201a8c0@HOMER.suse.lists.linux.kernel>
2002-01-26 22:43           ` Andi Kleen
     [not found] <fa.juevf8v.1u7ubb8@ifi.uio.no>
     [not found] ` <fa.h3u09pv.1v2k3bm@ifi.uio.no>
2002-01-26  2:12   ` Dan Maas
2002-01-26  3:45     ` Jamie Lokier
2002-01-26  4:33       ` Alexander Viro
2002-01-26  4:38         ` Andrew Pimlott
2002-01-26  4:59           ` Jamie Lokier
2002-01-26  5:11         ` Jamie Lokier
2002-01-25  2:15 Therien, Guy

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='018801c1a696$c55e95a0$0201a8c0@HOMER' \
    --to=nitrax@giron.wox.org \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lk@tantalophile.demon.co.uk \
    --cc=torvalds@transmeta.com \
    /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

Powered by JetHome