RE: [ACPI] ACPI mentioned on lwn.net/kernel

RE: [ACPI] ACPI mentioned on lwn.net/kernel

[Moore, Robert]

And I'll add my comments about so-called "bloat".

Given that the MS VC compiler consistently generates IA-32 code that is over
30% smaller than GCC, I would have to say that Linux would benefit far more
by directing all of the energy spent complaining about code size toward
optimizing the compiler.

Bob


> -----Original Message-----
> From: Therien, Guy [mailto:guy.therien@intel.com]
> Sent: Thursday, January 24, 2002 6:16 PM
> To: Grover, Andrew; 'lwn@lwn.net'
> Cc: Acpi-linux (E-mail); 'linux-kernel@vger.kernel.org'
> Subject: RE: [ACPI] ACPI mentioned on lwn.net/kernel
> 
> 
> I'll add that contrary to your statement, EVERY other OS with 
> ACPI support
> has it in their kernel. 
> Since Linux APM support calls the APM BIOS, which is not 
> easily changed, and
> ACPI calls AML that you can capture and change to fix any problems
> discovered using available tools, I'd say you were off with 
> the statement
> about "an interpreter that can run arbitrary, closed source 
> code" also. You
> can't "configure and dump" if you want runtime configuration and power
> management. If you need more info ask on or off the list.
> Regards,
> ACPIGuy
> 
> -----Original Message-----
> From: Grover, Andrew [mailto:andrew.grover@intel.com]
> Sent: Thursday, January 24, 2002 5:30 PM
> To: 'lwn@lwn.net'
> Cc: Acpi-linux (E-mail); 'linux-kernel@vger.kernel.org'
> Subject: [ACPI] ACPI mentioned on lwn.net/kernel
> 
> 
> Hi Jonathan,
> 
> As longtime subscribers to acpi-devel know, this seems to 
> come up every few
> months, but the criticisms mentioned in this week's lwn.net kernel
> development summary (http://lwn.net/2002/0124/kernel.php3) 
> prompt me to
> respond, lest my silence be taken for capitulation. ;-)
> 
> The concerns seem to be summed up when the article says, "ACPI brings
> substantial amounts of kernel bloat, reliability worries, and security
> concerns." Let me respond to each of those in reverse order:
> 
> 1) Security concerns
> - I think you mistook some kernel developers' off the cuff 
> comments about
> this as being real concerns, rather than trolling me (which 
> is apparently
> frightfully easy ;-). ACPI is only concerned with power management and
> configuration. It has nothing to do with digital rights 
> management, and that
> phrase does not appear anywhere in the 481 page ACPI 2.0 
> specification. The
> word "security" appears only twice.
> 
> 2) Reliability
> - One of ACPI's design goals was actually to reduce the OS's 
> susceptibility
> to bad BIOSs, compared to APM. OSs using APM suffer because 
> they must call
> into the BIOS -- relinquish control completely -- to perform power
> management. Under ACPI this is not the case. For example, to 
> get the current
> battery status, the steps the OS must perform are defined by the BIOS.
> However, since they are performed by the OS, the OS in fact 
> gains visibility
> into the process, and does not ever relinquish control to the BIOS.
> 
> 3) Bloat
> - Optimizing for size (or the various unloading schemes) 
> should wait until
> the codebase stabilizes. We're still adding major pieces of 
> functionality.
> - 100K really isn't that much, compared to other kernel 
> modules (determined
> via "size *.o"), or compared to memory installed on most 
> machines these
> days.
> - Bloat is compiler-dependent. Compiling the interpreter with 
> MSVC instead
> of GCC resulted in a ~40% size decrease.
> 
> Anyway, looking towards the future...
> 
> Our next release will have preliminary support for PCI IRQ 
> routing via ACPI
> (which should solve Jes's problem), along with a complete 
> rewrite of the
> ancillary drivers to adopt the new Linux 2.5 driver model. 
> When it is ready
> (target: Jan 31st) I'll post on both acpi-devel and 
> linux-kernel. My hope
> is, the more people gain familiarity of Linux's ACPI code by 
> testing and
> helping in its development, the more we all can accept it on 
> its merits, and
> start improving Linux's PnP and power management by using the improved
> functionality ACPI provides.
> 
> Regards -- Andy
> 
> 
> ----------------------------
> Andrew Grover
> Intel/MPG/Mobile Arch Lab
> andrew.grover@intel.com
> 
> 
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Horst von Brand]

"Moore, Robert" <robert.moore@intel.com> said:
> And I'll add my comments about so-called "bloat".
> 
> Given that the MS VC compiler consistently generates IA-32 code that is over
> 30% smaller than GCC, I would have to say that Linux would benefit far more
> by directing all of the energy spent complaining about code size toward
> optimizing the compiler.

Is it faster too? Or at least not slower? If not, what is the point?
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Ryan Cumming]

On January 25, 2002 07:50, Horst von Brand wrote:
> > Given that the MS VC compiler consistently generates IA-32 code that is
> > over 30% smaller than GCC, I would have to say that Linux would benefit
> > far more by directing all of the energy spent complaining about code size
> > toward optimizing the compiler.
>
> Is it faster too? Or at least not slower? If not, what is the point?

Storing 30% less executable pages in memory?  Reading 30% less executable 
pages off the disk? Performing 30% less relocations?

-Ryan

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Andreas Schwab]

Ryan Cumming <bodnar42@phalynx.dhs.org> writes:

|> On January 25, 2002 07:50, Horst von Brand wrote:
|> > > Given that the MS VC compiler consistently generates IA-32 code that is
|> > > over 30% smaller than GCC, I would have to say that Linux would benefit
|> > > far more by directing all of the energy spent complaining about code size
|> > > toward optimizing the compiler.
|> >
|> > Is it faster too? Or at least not slower? If not, what is the point?
|> 
|> Storing 30% less executable pages in memory?  Reading 30% less executable 
|> pages off the disk?

These are all startup costs that are lost in the noise the longer the
program runs.

|> Performing 30% less relocations?

30% less code does not imply 30% less relocations.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Ryan Cumming]

On January 25, 2002 08:15, Andreas Schwab wrote:
> These are all startup costs that are lost in the noise the longer the
> program runs.

Executable size is -not- just a startup cost. Larger executables will have a 
bigger memory footprint and less cache locality. A KDE desktop on 64megs of 
memory would be noticably more responsive if GCC generated executables the 
same size as VC++, due to less swap thrashing alone.

-Ryan

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Linus Torvalds]

In article <jeelkes8y5.fsf@sykes.suse.de>,
Andreas Schwab  <schwab@suse.de> wrote:
>|> 
>|> Storing 30% less executable pages in memory?  Reading 30% less executable 
>|> pages off the disk?
>
>These are all startup costs that are lost in the noise the longer the
>program runs.

That's a load of bull.

Startup costs tend to _dominate_ most applications, except for
benchmarks, scientific loads and games/multimedia. 

Not surprisingly, those three categories are also the ones where lots of
optimizer tuning is regularly done. But it's a _small_ subset of the
general application load.

Note that not only do startup costs often dominate the rest, they are
psychologically very important. From a user standpoint, an application
that loads "instantly" is mostly viewed as being much more pleasant than
one that takes longer to load, even if the latter were to run faster
once loaded.

This is also something that only gets worse and worse with time. Not
only do caches get more and more important (because the CPU core gets
ever faster compared to the outside world), but they get larger as well.

And what that leads to is that the cache warmup phase (which is linear
wrt size of the problem) gets relatively _slower_ and bigger compared to
the warm cache behaviour (ie the running phase). So optimizing for size
is (a) the right thing to do and (b) going to be even more so in the
future.

It's sad that gcc relegates "optimize for size" to a second-class
citizen.  Instead of having a "-Os" (that optimizes for size and doesn't
work together with other optimizations), it would be better to have a
"-Olargecode", which explicitly enables "don't care about code size" for
those (few) applications where it makes sense.

		Linus

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Jamie Lokier]

Linus Torvalds wrote:
> It's sad that gcc relegates "optimize for size" to a second-class
> citizen.  Instead of having a "-Os" (that optimizes for size and doesn't
> work together with other optimizations), it would be better to have a
> "-Olargecode", which explicitly enables "don't care about code size" for
> those (few) applications where it makes sense.

Btw, there have been suggestions that -Os may actually be faster for x86
code on current processors.

-- Jamie

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Martin Eriksson]

----- Original Message -----
From: "Jamie Lokier" <lk@tantalophile.demon.co.uk>
To: "Linus Torvalds" <torvalds@transmeta.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Saturday, January 26, 2002 4:41 AM
Subject: Re: [ACPI] ACPI mentioned on lwn.net/kernel


> Linus Torvalds wrote:
> > It's sad that gcc relegates "optimize for size" to a second-class
> > citizen.  Instead of having a "-Os" (that optimizes for size and doesn't
> > work together with other optimizations), it would be better to have a
> > "-Olargecode", which explicitly enables "don't care about code size" for
> > those (few) applications where it makes sense.
>
> Btw, there have been suggestions that -Os may actually be faster for x86
> code on current processors.

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?

This is how I did:
--- Makefile    Sat Jan 26 17:15:52 2002
+++ Makefile.Os Sat Jan 26 17:15:30 2002
@@ -88,7 +88,7 @@

 CPPFLAGS := -D__KERNEL__ -I$(HPATH)

-CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
+CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -Os \
          -fomit-frame-pointer -fno-strict-aliasing -fno-common
 AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)

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

- ABIT BP6(RU) - 2xCeleron 400 - 128MB/PC100/C2 Acer
- Maxtor 10/5400/U33 HPT P/M - Seagate 6/5400/DMA2 HPT S/M
- 2xDE-530TX - 1xTulip - Linux 2.4.17+ide+preempt

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Jeff Garzik]

Martin Eriksson wrote:
> 
> ----- Original Message -----
> From: "Jamie Lokier" <lk@tantalophile.demon.co.uk>
> To: "Linus Torvalds" <torvalds@transmeta.com>
> Cc: <linux-kernel@vger.kernel.org>
> Sent: Saturday, January 26, 2002 4:41 AM
> Subject: Re: [ACPI] ACPI mentioned on lwn.net/kernel
> 
> > Linus Torvalds wrote:
> > > It's sad that gcc relegates "optimize for size" to a second-class
> > > citizen.  Instead of having a "-Os" (that optimizes for size and doesn't
> > > work together with other optimizations), it would be better to have a
> > > "-Olargecode", which explicitly enables "don't care about code size" for
> > > those (few) applications where it makes sense.
> >
> > Btw, there have been suggestions that -Os may actually be faster for x86
> > code on current processors.
> 
> 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.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Jamie Lokier]

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.

-- Jamie

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Martin Eriksson]

----- 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

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Linus Torvalds]

On Sat, 26 Jan 2002, Martin Eriksson 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.

Note that while "-Os" exists and is documented, as far as I know gcc
doesn't actually do much with it. It really acts mostly as a "disable
certain optimizations" than anything else.

In the 3.0.x tree, it seems to change some of the weights of some
instructions, and it might make more of a difference there. But at the
same time it is quite telling that "-Os" doesn't even change any of the
alignments etc - because gcc developers do not seem to really support it
as a real option. It's an after-thought, not a big performance push.

		Linus

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Andrey Panin]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

On Sat, Jan 26, 2002 at 01:42:52PM -0800, Linus Torvalds wrote:
> 
> On Sat, 26 Jan 2002, Martin Eriksson 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.
> 
> Note that while "-Os" exists and is documented, as far as I know gcc
> doesn't actually do much with it. It really acts mostly as a "disable
> certain optimizations" than anything else.
> 

Stupid questions:
	- what stop us from using -mregparm=3 gcc switch ?
	- same with -Os -malign-loops=1 -malign-jumps=1 ?
	- any tool to measure perfomance gain/penalty of above ?

> In the 3.0.x tree, it seems to change some of the weights of some
> instructions, and it might make more of a difference there. But at the
> same time it is quite telling that "-Os" doesn't even change any of the
> alignments etc - because gcc developers do not seem to really support it
> as a real option. It's an after-thought, not a big performance push.
> 
> 		Linus
> 

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Andrey Panin]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Tue, Jan 29, 2002 at 02:14:32PM -0500, Mark Hahn wrote:
> > 	- what stop us from using -mregparm=3 gcc switch ?
> 
> I dimly recall that it can generage bad code, perhaps only
> on old compilers.

Bad code, hmm ... slow code or wrong code ?
IIRC gcc 2.95.3 declared as minimal requirement for kernel compilation,
so may be it's not an issue anymore ?

> 
> > 	- same with -Os -malign-loops=1 -malign-jumps=1 ?
> 
> 2 is probably always the lowest you should go, and indeed,
> I think that's all the compiler permits.
>

gcc (at least 2.95.2) permits 1, but i didn't check generated code.

> > 	- any tool to measure perfomance gain/penalty of above ?
> 
> lmbench.  it has to be a microbenchmark to measure this sort of thing,
> though a sanity check (kernel compile) would also be useful.

Thanks, i'll test these issues this weekend. 

Best regards.

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Felix von Leitner]

Thus spake Linus Torvalds (torvalds@transmeta.com):
> >These are all startup costs that are lost in the noise the longer the
> >program runs.
> That's a load of bull.

Agreed.  I like to plug my diet libc slides at this point which (I hope)
make a point about this with network programming as an example.  See
http://www.fefe.de/dietlibc/talk.pdf for details.

> Startup costs tend to _dominate_ most applications, except for
> benchmarks, scientific loads and games/multimedia.

> Not surprisingly, those three categories are also the ones where lots of
> optimizer tuning is regularly done. But it's a _small_ subset of the
> general application load.

Exactly.  However, due to these optimizations the trend goes to large
long-running monster applications like Mozilla or GNOME and KDE.  KDE
does not ask me whether I want to run those 20 processes all the time.
It just starts them.  And new processes are forked off a long running
process because the start-up cost has become so large.

> Note that not only do startup costs often dominate the rest, they are
> psychologically very important.

That is not just psychological.  Most developers would do good to visit
a close university or school and see what kind of machines they use
there.  Ever tried installing Debian on a Sparc SLC?  It took a little
over 24 hours.  Compiling a kernel takes over 12 hours on that box IIRC.
But that's not the point.  This hardware was very much usable a few
years ago.  Today it's practically futile to use it.  You are waiting
more than you are working.  On my desktop Athlon, 1.3 million CPU cycles
static start-up cost for running a dynamically linked glibc program may
not look like much.  But my statically linked ls does an ls -rtl of a
directory with 10 files in less time.

> It's sad that gcc relegates "optimize for size" to a second-class
> citizen.  Instead of having a "-Os" (that optimizes for size and doesn't
> work together with other optimizations), it would be better to have a
> "-Olargecode", which explicitly enables "don't care about code size" for
> those (few) applications where it makes sense.

What do you mean with "does not work together with other optimizations"?
I use -Os all the time.  Actually, -Os often produces faster code than
-O2 or -O3!  What other optimizations do you mean?  I don't need much
other optimizer options besides -fomit-frame-pointer and -march=athlon
if you link PIC code and use an Athlon.

And since -funroll-loops and -finline-functions are enabled explicitly
(or the latter with -O3 and larger by people who don't know what they
are doing), I think gcc already does what you want it to do ;)

Felix

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Florian Weimer]

Felix von Leitner <usenet-20020126@fefe.de> writes:

> What do you mean with "does not work together with other optimizations"?

You cannot both enable -Os and prefetching support, for example (at
least with certain GCC versions).

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Martin Dalecki]

Linus Torvalds wrote:

>In article <jeelkes8y5.fsf@sykes.suse.de>,
>Andreas Schwab  <schwab@suse.de> wrote:
>
>>|> 
>>|> Storing 30% less executable pages in memory?  Reading 30% less executable 
>>|> pages off the disk?
>>
>>These are all startup costs that are lost in the noise the longer the
>>program runs.
>>
>
>That's a load of bull.
>
>Startup costs tend to _dominate_ most applications, except for
>benchmarks, scientific loads and games/multimedia. 
>
Well the situation is in fact even more embarassing if you do true 
benchmarking on really long running
(well that's relative of course) applications. I personaly did once in a 
time a benchmarking on the good
old tex running trhough a few hundert pages long document. Well the -O2 
version was actually about 15%
*SLOWER* then the -Os version. That's becouse in real world 
applications, which don't do numerical
calculations but most of the time they do "decision taking" the whole 
mulitpipline sceduling get's
outwighted by the simple cache pressure thing by *far*.

The whole GCC developement is badly misguided on this for *sure*. They 
develop for numerics where
most programs are kind of doing a controlling/decision taking job.
 Well I know I should try this with the kernel one time...

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Dieter Nützel]

On Sunday, 27. January 2002 13:56, Martin Dalecki wrote:
> Linus Torvalds wrote:
>
> > In article <jeelkes8y5.fsf@sykes.suse.de>,
> > Andreas Schwab  <schwab@suse.de> wrote:
> >
> >>|> 
> >>|> Storing 30% less executable pages in memory?  Reading 30% less
> >>|> executable 
> >>|> pages off the disk?
> >>
> >>These are all startup costs that are lost in the noise the longer the
> >>program runs.
> >>
> >
> >That's a load of bull.
> >
> >Startup costs tend to _dominate_ most applications, except for
> >benchmarks, scientific loads and games/multimedia. 
> >
> Well the situation is in fact even more embarassing if you do true
> benchmarking on really long running (well that's relative of course)
> applications. I personaly did once in a time a benchmarking on the good old
> tex running trhough a few hundert pages long document. Well the -O2 version
> was actually about 15% *SLOWER* then the -Os version. That's becouse in real
> world applications, which don't do numerical calculations but most of the
> time they do "decision taking" the whole mulitpipline sceduling get's
> outwighted by the simple cache pressure thing by *far*.
>
> The whole GCC developement is badly misguided on this for *sure*. They
> develop for numerics where most programs are kind of doing a
> controlling/decision taking job.
> Well I know I should try this with the kernel one time...

I can second that.
Now that I'm running AMD Athlon's since August 1999 I found during 3D 
development/benchmarking (OpenGL/Mesa) that the following GCC flags are 
"best" for Athlon/Duron with gcc-2.95.3:

-O -mcpu=k6 -pipe -mpreferred-stack-boundary=2 -malign-functions=4 
-fschedule-insns2 -fexpensive-optimizations

I even compile the whole kernel with a little different flags setting. It is 
smaller and "faster" with them.

HOSTCFLAGS      = -Wall -Wstrict-prototypes -O -fomit-frame-pointer -mcpu=k6 
-pipe -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 
-fexpensive-optimizations

CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O \
          -fomit-frame-pointer -fno-strict-aliasing -fno-common

linux/arch/i386/Makefile:
ifdef CONFIG_MK7
CFLAGS += $(shell if $(CC) -march=athlon -S -o /dev/null -xc /dev/null 
>/dev/null 2>&1; then echo "-march=athlon"; else echo "-mcpu=k6 -pipe 
-mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 
-fexpensive-optimizations"; fi)
endif

Regards,
	Dieter

-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel@hamburg.de

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Andi Kleen]

"Martin Eriksson" <nitrax@giron.wox.org> writes:

> -CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
> +CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -Os \
>           -fomit-frame-pointer -fno-strict-aliasing -fno-common
>  AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)

You should remove the -malign-* options in arch/i386/Makefile too.
Most of -Os win normally comes from doing less aggressive padding,
but the kernel overrides this.

Also gcc 3.0 and gcc 3.1-snapshots should be somewhat better at 
implementing -Os. 

-Andi

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Dan Maas]

> These are all startup costs that are lost in the noise
> the longer the program runs.

This may be true for environments where people mostly run a handful of
monolithic applications (*ahem* windows) but look at typical Linuxy things
like:

make (compiler, assembler, linker processes...)
forking servers (Apache 1.x...)
*./configure scripts* (a big one!!!)
etc...

Startup cost is likely to be a big factor here...

Regards,
Dan

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Jamie Lokier]

Dan Maas wrote:
> This may be true for environments where people mostly run a handful of
> monolithic applications (*ahem* windows) but look at typical Linuxy things
> like:
> 
> make (compiler, assembler, linker processes...)
> forking servers (Apache 1.x...)
> *./configure scripts* (a big one!!!)
> etc...
> 
> Startup cost is likely to be a big factor here...

Btw, a little story about startup times and Linux.

I once wrote a Perl script that needed to know the current directory.
It did:

   use POSIX 'getcwd'
   getcwd(...)

After a few months, I was annoyed by the slowness of this script
(compared with other scripts) and decided to try speeding it up.  It
turns out that the above two lines took about 0.25 of a second, and that
was the dominant running time of the script.

I replaced getcwd() with `/bin/pwd`.  Lo!  It took about 0.0075 second.

Says very good things about Linux' fork, exec and mmap times, and about
Glibc's dynamic loading time, I think.

-- Jamie

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Alexander Viro]

On Sat, 26 Jan 2002, Jamie Lokier wrote:

> I once wrote a Perl script that needed to know the current directory.
> It did:
> 
>    use POSIX 'getcwd'
>    getcwd(...)
> 
> After a few months, I was annoyed by the slowness of this script
> (compared with other scripts) and decided to try speeding it up.  It
> turns out that the above two lines took about 0.25 of a second, and that
> was the dominant running time of the script.
> 
> I replaced getcwd() with `/bin/pwd`.  Lo!  It took about 0.0075 second.
> 
> Says very good things about Linux' fork, exec and mmap times, and about
> Glibc's dynamic loading time, I think.

Most likely it says very bad things about getcwd() implementation in Perl
compared to sys_getcwd() in the kernel.  The latter just walks the chain
of dentries copying ->d_name.name into the buffer.  The former... my guess
would be stat ".", open "..", readdir from it, stat every damn object in
there until you find one with the right ->st_ino, put its name as the
last component and repeat the whole thing until you reach root...

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Andrew Pimlott]

On Fri, Jan 25, 2002 at 11:33:44PM -0500, Alexander Viro wrote:
> 
> On Sat, 26 Jan 2002, Jamie Lokier wrote:
> 
> > I once wrote a Perl script that needed to know the current directory.
> > It did:
> > 
> >    use POSIX 'getcwd'
> >    getcwd(...)
> > 
> > After a few months, I was annoyed by the slowness of this script
> > (compared with other scripts) and decided to try speeding it up.  It
> > turns out that the above two lines took about 0.25 of a second, and that
> > was the dominant running time of the script.
> > 
> > I replaced getcwd() with `/bin/pwd`.  Lo!  It took about 0.0075 second.
> > 
> > Says very good things about Linux' fork, exec and mmap times, and about
> > Glibc's dynamic loading time, I think.
> 
> Most likely it says very bad things about getcwd() implementation in Perl
> compared to sys_getcwd() in the kernel.

No no no--it says very bad things about 'use POSIX', and in general
about overhead-creep in the perl library.

Andrew

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Jamie Lokier]

Andrew Pimlott wrote:
> > Most likely it says very bad things about getcwd() implementation in Perl
> > compared to sys_getcwd() in the kernel.
> 
> No no no--it says very bad things about 'use POSIX', and in general
> about overhead-creep in the perl library.

I ended up calling sys_getcwd from Perl as it's extremely fast.  Even
faster if you hard code the syscall number instead of reading the header
file in Perl :-)

However, I was still impressed by the 0.0075s for a pipe/fork/exec.

'use POSIX' is very slow, but Perl's getcwd() is pretty slow too -- it
does the old fashioned directory walk.  We cannot blame it for being
portable.

-- Jamie

Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Jamie Lokier]

Alexander Viro wrote:
> Most likely it says very bad things about getcwd() implementation in Perl
> compared to sys_getcwd() in the kernel.  The latter just walks the chain
> of dentries copying ->d_name.name into the buffer.  The former... my guess
> would be stat ".", open "..", readdir from it, stat every damn object in
> there until you find one with the right ->st_ino, put its name as the
> last component and repeat the whole thing until you reach root...

I better correct my statement.  Just had a look at the old Perl script
in question.

I was originally using 'use Cwd; getcwd()'.  That was really slow and it
does exactly what Alex says.  Even though you don't need to call stat()
on each entry: the readdir system call returns the inode numbers for all
directories that aren't mount points, but Perl doesn't give that
information to its libraries (for the sake of portability).

Then I switched to 'use POSIX; getcwd()'.  That was faster, but still
distressingly slow (i.e. noticable in human terms).  POSIX::getcwd()
forks and execs to call /bin/pwd, and is quite fast.  But 'use POSIX' is
quite slow.  Shame really, because the implementation is in a shared
library; it's just the 'use POSIX' importing part that's slow.

Then I tried `/bin/pwd' myself since the POSIX function uses it.  That
was pretty fast and I was impressed with Linux for being that fast.  Of
course it is still 1.7 million cycles which is not brilliant, but it was
faster than I'd expected for a pipe/fork/exec.

Finally I just did the getcwd() system call myself.  Used a hard-coded
system call number, because reading it from a header file was slow.
Linus was right about startup times in this case.

enjoy,
-- Jamie

RE: [ACPI] ACPI mentioned on lwn.net/kernel

[Therien, Guy]

I'll add that contrary to your statement, EVERY other OS with ACPI support
has it in their kernel. 
Since Linux APM support calls the APM BIOS, which is not easily changed, and
ACPI calls AML that you can capture and change to fix any problems
discovered using available tools, I'd say you were off with the statement
about "an interpreter that can run arbitrary, closed source code" also. You
can't "configure and dump" if you want runtime configuration and power
management. If you need more info ask on or off the list.
Regards,
ACPIGuy

-----Original Message-----
From: Grover, Andrew [mailto:andrew.grover@intel.com]
Sent: Thursday, January 24, 2002 5:30 PM
To: 'lwn@lwn.net'
Cc: Acpi-linux (E-mail); 'linux-kernel@vger.kernel.org'
Subject: [ACPI] ACPI mentioned on lwn.net/kernel


Hi Jonathan,

As longtime subscribers to acpi-devel know, this seems to come up every few
months, but the criticisms mentioned in this week's lwn.net kernel
development summary (http://lwn.net/2002/0124/kernel.php3) prompt me to
respond, lest my silence be taken for capitulation. ;-)

The concerns seem to be summed up when the article says, "ACPI brings
substantial amounts of kernel bloat, reliability worries, and security
concerns." Let me respond to each of those in reverse order:

1) Security concerns
- I think you mistook some kernel developers' off the cuff comments about
this as being real concerns, rather than trolling me (which is apparently
frightfully easy ;-). ACPI is only concerned with power management and
configuration. It has nothing to do with digital rights management, and that
phrase does not appear anywhere in the 481 page ACPI 2.0 specification. The
word "security" appears only twice.

2) Reliability
- One of ACPI's design goals was actually to reduce the OS's susceptibility
to bad BIOSs, compared to APM. OSs using APM suffer because they must call
into the BIOS -- relinquish control completely -- to perform power
management. Under ACPI this is not the case. For example, to get the current
battery status, the steps the OS must perform are defined by the BIOS.
However, since they are performed by the OS, the OS in fact gains visibility
into the process, and does not ever relinquish control to the BIOS.

3) Bloat
- Optimizing for size (or the various unloading schemes) should wait until
the codebase stabilizes. We're still adding major pieces of functionality.
- 100K really isn't that much, compared to other kernel modules (determined
via "size *.o"), or compared to memory installed on most machines these
days.
- Bloat is compiler-dependent. Compiling the interpreter with MSVC instead
of GCC resulted in a ~40% size decrease.

Anyway, looking towards the future...

Our next release will have preliminary support for PCI IRQ routing via ACPI
(which should solve Jes's problem), along with a complete rewrite of the
ancillary drivers to adopt the new Linux 2.5 driver model. When it is ready
(target: Jan 31st) I'll post on both acpi-devel and linux-kernel. My hope
is, the more people gain familiarity of Linux's ACPI code by testing and
helping in its development, the more we all can accept it on its merits, and
start improving Linux's PnP and power management by using the improved
functionality ACPI provides.

Regards -- Andy


----------------------------
Andrew Grover
Intel/MPG/Mobile Arch Lab
andrew.grover@intel.com


_______________________________________________
Acpi-devel mailing list
Acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-devel