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

[Felix von Leitner <usenet-20020126@fefe.de>]

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