Mail Archives: djgpp/2006/04/06/17:30:36
............
> >Unfortunately, that detection is wrong for a function like clock(). I
> >may be going out on a limb there, but this could require a change to
> >the declaration of clock() and similar functions to forbid this kind
> >of optimization.
>
> That kind of optimization is forbidden unless the (external) function
> is declared with attributes pure or const (clock is not), or the
> compiler can sufficiently determine the effect of the (internal)
> function: even declaring the internal function static did not change
> the code. If the compiler had inlined or reorganized the internal
> function better, I could understand why it did what it did, but when
> the workaround is declaring an auto variable (local) static, looks to
> me like a bug: something is toggled the wrong way here.
>
After thinking it over and without thorough studies
of C99 docs, I am still convinced that I have no
right to blame gcc 410 for rearranging the code.
But this does not necessarily stop me to moan
about the fact that gcc 344 can get about the
same performance on my computer without
applying equally fancy tricks to the code.
The reason why I think that I have to accept gcc's
new features is due to the following reasons:
-----------
t0=clock();
int ackret=Ack(3, n);
t1=clock();
printf("Ack(3,%d): %d\n", n, ackret);
printf("Time1: %g secs\n", 1.0*(t1-t0)/CLOCKS_PER_SEC);
-----------
Ack() is no external function, so gcc has full control
over code generation and can optimize it as much
as it wants while obeying the only rule required:
Get its return value ready when its is needed.
This would be in the first printf() function.
The clock() function is an ordinary external function,
which has no special meaning to gcc other than that
its return value is required in the second printf()
function.
There is no dependency between clock() and Ack(),
so gcc has no reason to apply a specific sequence
to code generation.
It also makes no difference whether the clock()
return values are assigned to locals or globals,
because gcc can implicitly rule out that Ack()
is accessing external variables.
When using local variables (e.g. ackret) I have
to be aware that the variable does not need to
exist in memory. Therefore gcc is not required
to assume that 'ackret' could be accessed by the
clock() function.
If I want to time Ack(), I have to get gcc to suspect
that Ack's return value is needed earlier than in the
printf() function. This would be before the 2nd
clock() function is called.
I can do this either by assigning its return value
to a static, which in theory would be accessible
by the subsequent clock() function.
Alternatively I can accept a performance hit and
create Ack() as an external function which cannot
be ripped apart due to obvious reasons.
Thoughts?
- Raw text -