speed and size optimizations

[Clifford Wolf]

Hi,

as everyone here might know, in many cases a programm "optimized for size"
runs much faster than the same program "optimized for speed".

<common knowledge>
The reason for this is that speed-optimized is in many cases significant
larger than unoptimized (or *surprise* size optimized) code: many NOPs
for alignments, loop unrolling, etc..

Now many apps (mostly GUI apps) do execute most code-pieces only once in a
while, so that cpu cache misses, etc. become the most critical part for
execution speed. Ergo: size optimized code is often faster.
</common knowledge>

However: Almost every program consist of some compution parts which should
be optimized for speed and a huge framework for user-interaction, config
file parsing, etc. which should be optimized for size. But support for
that is missing in GNU autoconf: a standard configure script only knowns
about one CC and one CLFAGS.

I'm currently working on a pretty hackish solution for the problem to be
used in later version of ROCK Linux (www.rocklinux.org). I'm going to talk
about it a bit at the end of this mail...

IMO it would absolutely make sense if gnu autoconf (and automake) would
have a generic support for at least two compilers (and flags): One for
speed and one for size. So it would be possible (once people start using
that in their packages) to just export environment variables such as

        CC_SIZE = gcc-2
        CFLAGS_SIZE = -Os

        CC_SPEED = gcc-3
        CFLAGS_SPEED = -O3

        (as well as fallback CC and CFLAGS for older packages)

And run "./configure; make; make install" as usual whenever building a
package. The result would be binaries which are (a) faster than the
same package just built with 'gcc-3 -O3' and (b) smaller.

I can guess that this is likely to require a major redesign of some
autoconf parts - but I do know from my tests that this does absolutely
make sense (if creating good binaries is a declared target).

What do you think about that?

<off-topic>
About the "hackish solution" I mentioned above:

ROCK Linux is a tool for building UNIX-like operating systems from source.
Currently we support gcc2, gcc3 and icc as compilers; glibc and dietlibc
as c libraries, etc. ROCK 2.1 will not have the "Linux" in the name
anymore because we are going to integrate support for Mach+Hurd and BSD
kernels. ROCK is passing some wrappers to configure instead of the
compiler to make some last-minute decisions for compiler and command line
options.

I'm now playing around with writing a "system profiler" which is running
on a system with all binaries containing debug symbols. Whenever a
process timeslice expires and the scheduler interrupts the process, the ip
of the process will be used to determine the current vma and the relative
adress in the vma. Now the debug symbols in the elf binary the vma is
mapped to can be used to get the original c source file for the code
beeing interrupted. This information is stored in a profile database.

The profile databases of various test users are then merged and analyzed
to get a list of c source files containing code which should be built with
speed optimizations - everything else is optimized for size.

This is far away from beeing perfect but it is better than nothing to
optimize at least the really common tools many people are using (such as
the gnu toolchain and the kde desktop). Once it is finished, this could
also be very usefull for program authors to generate profiles for their
packages when autoconf has support for two standard compilers (I'm sure
this will happen - earlier or later).
</off-topic>

BTW: Does autoconf support running a test with -fprofile-arcs and then
rebuilding with -fbranch-probabilities ?

yours,
 - clifford

-- 
| Clifford Wolf /-----=[ www.clifford.at ]==[ Tel: +43-699-10063494 ]=-\
|--------------/ diestartseite.at vocat.cc =[ Fax: +43-2235-42788-4 ]=-|
|-=[ EDEN Creations -- www.edenevents.at ]==[ IRC: www.freenode.net ]=-|
\==[ www.rocklinux.org ]===[ www.rocklinux.net ]===[ www.linbit.com ]==/

2B OR (NOT 2B) That is the question. The answer is FF.