[gentoo-amd64] Re: About gcc 4.1.1

[Duncan]

Ronan Klyne <rklyne@×××××.com> posted 44F7F407.4090203@×××××.com,
excerpted below, on  Fri, 01 Sep 2006 09:49:11 +0100:

> I'm tempted to use the nice shiny gcc 4.1.1 to build a new kernel - is
> this going to make much (or any) difference?
> A more general form of the question: does 4.1.1 on amd64 produce faster
> binaries, or produce binaries faster?

Depending on your optimizations, both in your CFLAGS and whether the
sources have been rewritten to take advantage of new 4.x features such as
hidden functions in C++, 4.1.1 seems to produce faster binaries, slower.
Many of the newer high-level optimizations involve extra runs thru the
code, or extra steps during runs that were already there.  In some cases
these optimizations were already there previously, only they had to be
invoked individually where they are now default at some -O level
(where previously they weren't tested enough to be default, or were
considered too expensive in terms of compile time), other times the
optimizations are entirely new or more efficient than they were previously
(finding opportunities that were missed before, say).

This is the trend in general.  Cross-reference the various discussions on
LKML (Linux Kernel Mailing List) about dropping support for older
compilers, for instance.  I think the oldest they support with the latest
2.6 kernels is gcc 3.2 (for x86 of course, amd64 support was added in
3.3 IIRC, tho there were "hammer patched" 3.2 versions, tho maybe it was
3.1/3.2 instead of 3.2/3.3, IDR exactly), but it was 2.95 or there abouts
for the longest time, in part because 2.95 was faster at recompiling
kernels after tweaking the sources a bit, to just test that the new code
worked, so they didn't really care how fast it actually ran in production,
thus didn't care about optimizations unless they affected bugs.

As for building your kernel with it, again, it could make a difference --
it depends both on your CFLAGS and on some of the choices you made in
configuring the kernel.  In particular, -Os and the kernel's optimize for
size option are likely to be more efficient.  A kernel optimized for size
may in itself run slightly slower, but being slightly smaller, fits in the
cache better, and code runs faster from cache than from main memory. 
Consider what happens when switching between user space application and
kernel context, for example when an app allocates or releases memory, when
it talks to the network, or when it checks for and opens files as many
applications do hundreds of times while starting up.  Smaller code, even
tho slower if memory was all the same speed, ends up being faster because
more of it fits in fast cache memory, and less ends up being swapped
between cache and main memory every time there's a switch between
applications or between userspace context and kernel context within an
application.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list