Re: gcc 3.2.1 optimizer degradation (strlen, -O2)

["Marcel Cox" <marcel_cox at hotmail dot com>]

2 things which might still have an influence:

1) Processor. Make sure you are both times optimizing for the same
processor. If you have a simple pentium for instance, you can use the
option -march=pentium to generate optimal code for your processor

2) GCC now includes code to keep the stack aligned at multiples of 16 bytes.
This improves performance for variables of type double or long double, and
is also required for SSE intructions to be able to safely use data on the
stack. However in examples like yours, it does not have any benefot, but
causes a slowdown because of the overhead of the stack adjustment
intructions. If you use the option -mpreferred-stack-boundary=2 ,for your
main.c file, then the loop that calls strlen becomes much tighter and should
be faster
BTW I always use this option on code that does not or hardly use any
floating point operations.

3) Except for Pentium4, GCC 3.2.1 does not inline the strlen function in
your code as it considers the gain to be not worthwhile. You can however
force it to do so anyway by using the option -minline-all-stringops and see
if that makes a difference.

Marcel

"Leonid Pauzner" <uue@pauzner.dnttm.ru> wrote in message
2.7.9.WQJB.H8KFN8@pauzner.dnttm.ru">news:2.7.9.WQJB.H8KFN8@pauzner.dnttm.ru...
>
> [I was wrong in my previous post, lost -O2]
> You are right.
> 2.95 do inline strlen(), while 3.2.1 is not.
> Nevertheless I got the following results in my test:
>
> gcc321 -O2
> strlen.c   20 sec
> strlen2.c  17 sec
> (library?) 14 sec
>
> gcc295 -O2
> strlen.c   16 sec  (main.c was compiled without -O)
> strlen2.c  11 sec  (main.c was compiled without -O)
> (builtin)   8 sec
>
> So the difference exists but not that dramatic.
>
>
>