FreeLists / haiku-appserver / [haiku-appserver] Re: [Haiku-commits] r14599 - haiku/trunk/src/servers/app

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2005-11-01 at 19:38:19 [+0100], Adi Oanca wrote:
> Ingo Weinhold wrote:
> > On 2005-11-01 at 00:02:58 [+0100], Adi Oanca wrote:
> >>Ingo Weinhold wrote:
> > 
> > Regarding books about this kind of optimization, one can usually throw 
> > them
> > away when the next compiler version is released.
> 
>     Maybe. It's good to know such things anyway. :-)
> 
> > Regarding tests, I couldn't
> > help it and compiled these two (nonsense) functions:
> > 
> > static void
> > test1(const char *longString)
> > {
> >     for (int i = 0; i < 1000; i++) {
> >         const char *str = longString + i;
> >         printf("pos: %d\n", str - longString);
> >     }
> > }
> > 
> > static void
> > test1(const char *longString)
> > {
> >     const char *str;
> >     for (int i = 0; i < 1000; i++) {
> >         str = longString + i;
> >         printf("pos: %d\n", str - longString);
> >     }
> > }
> > 
> > Compiling without optimization results in different assembler code. Just 
> > as
> > suspected. Unlike you suggest, there is no more overhead involved in the
> > first version.
> 
>     No stack pointer addition and subtraction for every iteration?

There are stack pointer operations, but they have only partially to do with 
the local str variable. There's the preparation and cleanup of the stack for 
the printf() invocation. Which has to be done anyway (well, that's not 
completely right -- the adjustment of the stack pointer before invoking 
printf() would probably be omitted, were there no local variables at all 
(i.e. also no index variable i)); only the offsets are different for the 
first and second code snippet.

> > On x86 local variables are referenced relative to the stack frame pointer
> > (ebp). Declaring a local variable does not result in actual code, it only
> > causes the compiler to reserve space for the variable while compiling. In 
> > the
> > first version, the compiler reserves the four bytes at -4(epb) for i and 
> > the
> > four bytes at -8(ebp) for str. In the second version things are just
> > reversed. No effect on performance.
> 
>     Hmmm... GCC is smart? :-)

At least not completely dumb.

>     Are you sure not other instruction is executed in the first test?

Feel free to play with it yourself (pass "-S" instead of "-c" to let gcc 
generate assembly). At least the fact that with optimization turned on the 
same code is generated for both functions should be reassuring that gcc is 
clever enough to juggle with local variables in an effective way.

CU, Ingo