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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:41 EST