Is there a benchmark or set of benchmarks that would allow me to test the
suitability of the CONFIG_CC_OPTIMIZE_FOR_SIZE kernel config option?
It seems to me that the benefit of this option is very dependant on the
amount of CPU cache installed, with the compiler code generation being a
secondary factor. The use, or not, of CONFIG_CC_OPTIMIZE_FOR_SIZE is
basically an act of faith without knowing how it impacts my particular
environment.
I've got a Pentium4 CPU with 512KB of L2 cache, and I'm using GCC v3.3.3.
How can I determine whether or not CONFIG_CC_OPTIMIZE_FOR_SIZE should be
used for my system?
Thanks.
On Sun, 2005-01-16 at 10:40 -0500, Steve Snyder wrote:
> Is there a benchmark or set of benchmarks that would allow me to test the
> suitability of the CONFIG_CC_OPTIMIZE_FOR_SIZE kernel config option?
>
> It seems to me that the benefit of this option is very dependant on the
> amount of CPU cache installed, with the compiler code generation being a
> secondary factor. The use, or not, of CONFIG_CC_OPTIMIZE_FOR_SIZE is
> basically an act of faith without knowing how it impacts my particular
> environment.
>
> I've got a Pentium4 CPU with 512KB of L2 cache, and I'm using GCC v3.3.3.
> How can I determine whether or not CONFIG_CC_OPTIMIZE_FOR_SIZE should be
> used for my system?
it also saves 400 kb of memory that can be used by the pagecache now...
that doesn't show in a microbenchmark but it's a quite sizable gain if
you remember that a disk seek is 10msec..that is a LOT of cpu cycles..
On Jan 16 2005, Arjan van de Ven wrote:
> On Sun, 2005-01-16 at 10:40 -0500, Steve Snyder wrote:
> > Is there a benchmark or set of benchmarks that would allow me to test
> > the suitability of the CONFIG_CC_OPTIMIZE_FOR_SIZE kernel config
> > option?
>
> it also saves 400 kb of memory that can be used by the pagecache now...
> that doesn't show in a microbenchmark but it's a quite sizable gain if
> you remember that a disk seek is 10msec..that is a LOT of cpu cycles..
Since I'm using a Duron 600MHz (the lowest model, AFAIK), I decided to
compile a new kernel with the -Os option. Despite the scary warning on the
help, it seems to be working fine for the first few moments with Debian's
testing gcc (3.3.5).
I haven't noticed any other improvement, but I guess that more memory
available to applications would never hurt (as long as stability is
preserved).
I will also try to compile other applications (like Firefox), since my main
memory is so limited and the small cache of my processor would surely
appreciate it.
Perhaps it is time to give the tiny-linux project a try to see what other
optimizations I can achieve.
Just another data point, Rog?rio.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rog?rio Brito - [email protected] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Sun, Jan 16, 2005 at 10:40:12AM -0500, Steve Snyder wrote:
> Is there a benchmark or set of benchmarks that would allow me to test the
> suitability of the CONFIG_CC_OPTIMIZE_FOR_SIZE kernel config option?
>
> It seems to me that the benefit of this option is very dependant on the
> amount of CPU cache installed, with the compiler code generation being a
> secondary factor. The use, or not, of CONFIG_CC_OPTIMIZE_FOR_SIZE is
> basically an act of faith without knowing how it impacts my particular
> environment.
>
> I've got a Pentium4 CPU with 512KB of L2 cache, and I'm using GCC v3.3.3.
> How can I determine whether or not CONFIG_CC_OPTIMIZE_FOR_SIZE should be
> used for my system?
>
> Thanks.
In theory, -O2 should produce faster code.
In practice, I don't know about any recent benchmarks comparing -Os/-O2
kernels.
In practice, I doubt it would make any noticable difference if the
kernel might be faster by let's say 1% with one option compared to the
other one.
The main disadvantage of -Os is that it's much less tested for kernel
compilations, and therefore miscompilations are slightly more likely.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi Adrian,
On Wed, Jan 19, 2005 at 05:17:39AM +0100, Adrian Bunk wrote:
> In theory, -O2 should produce faster code.
>
> In practice, I don't know about any recent benchmarks comparing -Os/-O2
> kernels.
>
> In practice, I doubt it would make any noticable difference if the
> kernel might be faster by let's say 1% with one option compared to the
> other one.
>
> The main disadvantage of -Os is that it's much less tested for kernel
> compilations, and therefore miscompilations are slightly more likely.
In fact, I've been compiling all my kernels with -Os for at least 2 years
with gcc-2.95.3. -Os and -O2 produce nearly the same code on this compiler,
it's even difficult to find algorithms which produce fairly different code
with it. But things get different with gcc-3.3. -Os produces *really*
smaller code (sometimes up to 20% smaller than -Os on gcc-2.95.3), but this
code also becomes fairly slower, and disassembling it sometimes shows what
can be called stupid code, because speed optimization completely disappears
eventhough sometimes both size and speed could be optimized (eg: by switching
two instructions to prevent pipelines stalls). On various code, I found
gcc-3.3 -Os to deliver about 30% less performance than -O2. On the other hand,
gcc-3.3 -O2 produces bigger and sometimes faster code than gcc-2.95 -O2.
So it's difficult to say which one is better, it really depends on what you
do with it.
I have not benchmarked any gcc-3.3 -Os kernel yet, though I've already been
running some of them accidentely because of an old .config which gets rebuild
on a machine which only has gcc-3.3. I've not noticed miscompilations nor
really perceptible slowdowns, but I've not measured this last point.
What I often found efficient to both reduce code size and improve speed is
to play with code alignment and stack boundary. Using
"-mpreferred-stack-boundary=2" keeps the stack 32-bit aligned, which removes
some entry and leave code in all functions (and esp, ...). Code alignment
with -malign-loops=0, -malign-jumps=0 and -malign-functions=0 reduces the
code size while not really affecting its speed (or just slightly increase
some of these params if you find speed problem).
Regards,
Willy