In article <3e7a0dca@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> So, please upgrade. gcc-3.2 produces faster POVRay-code anyways.
> (Or, complain about my ignorance in case I am wrong at this issue.)

Mael claimed to be using gcc 3.2.  The last time I used gcc 2.95 was with
POV-Ray 3.1g on an Irix a long time ago.  And in fact inlining can happen in
the backend in some compilers (I don't know where or how often gcc does it
currently).  So my statement was not gcc specific but general about certain
compilers, leaving completely open whether or not the specific gcc version
and configuration used has a problem or not.  Visual Studio also used to
have problems with it (I didn't check in its current version so far).

The compiler I am using on the Mac (Metrowerks CodeWarrior) has supported
very advanced inlining features for several years, so I haven't seen a
problem like this locally (or I can't remember it, it is really long ago).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

>> So, please upgrade. gcc-3.2 produces faster POVRay-code anyways.
>> (Or, complain about my ignorance in case I am wrong at this issue.)
> 
> Mael claimed to be using gcc 3.2. 
>
Hmm. In this case I suggest compiling with -Winline and see if the 
reason for the time difference is really the inlining. 
In case -Winline does not give a warning, it may help if we have a 
look at the assembler code generated by gcc. 
Either there is a bug in gcc (-Winline does not work correctly), 
or the speed difference is due to some other reason (different code 
layout better for cache or whatever). 

Any other ideas?

Wolfgang

Post a reply to this message

> WAIT. Because it seems you [Mael] are using an outdated version of gcc.

g++ -v
version gcc 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

I'm by no mean a gcc expert but try the following :

g++ -S -O2 -Winline -Wno-multichar -c isosurf.cpp
grep Evaluate_Function isosurf.s
 call _Z17Evaluate_FunctionjPd
 call _Z17Evaluate_FunctionjPd
 call _Z17Evaluate_FunctionjPd
 call _Z17Evaluate_FunctionjPd
 call _Z17Evaluate_FunctionjPd
 call _Z17Evaluate_FunctionjPd
 .section .gnu.linkonce.t._Z17Evaluate_FunctionjPd,"ax",@progbits
 .weak _Z17Evaluate_FunctionjPd
 .type _Z17Evaluate_FunctionjPd,@function
_Z17Evaluate_FunctionjPd:
 .size _Z17Evaluate_FunctionjPd,.Lfe17-_Z17Evaluate_FunctionjPd

then move the inline functions at beginning of file..

g++ -S -O2 -Winline -Wno-multichar -c isosurf.cpp
grep Evaluate_Function isosurf.s
(nothing)

I think that -Winline will warn if the function cannot be inlined (looking
at gcc doc this can happen for example if it uses varargs), but here the
functions *are* inlinable(? :)

M

Post a reply to this message

Mael wrote:
>> WAIT. Because it seems you [Mael] are using an outdated version of gcc.
> 
> g++ -v
> version gcc 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
> 
> I think that -Winline will warn if the function cannot be inlined (looking
> at gcc doc this can happen for example if it uses varargs), but here the
> functions *are* inlinable(? :)
> 
Well, the info states: 
  Using `-Winline' will warn when a function marked `inline' could not be
  substituted, and will give the reason for the failure.

And when using gcc-2.95, I get tons of warnings about functions which 
cannot be inlined which I do not get with gcc-3.2. 

OTOH, I made a simple test case which proves that you are right: 

--------<test.cpp>--------
static inline int foo(int x);

int main()
{
        return(foo(17));
}

inline int foo(int x)
        {  return(x);  }
--------------------------

In the above case, foo() will actually NOT be inlined and gcc will 
not say a word about that. However, when yo move the foo() def above 
main(), then it WILL be inlined. 

HOWEVER, compiling the above code with gcc-2.95.3, you get: 
test.cc: In function `int main()':
test.cc:1: warning: can't inline call to `int foo(int)'
test.cc:5: warning: called from here

which is what I would definitely expect -Winline to produce in this 
case!

When moving foo() def above main(), the warning goes away and foo() 
gets properly inlined. 

I'll talk to some gcc developer about that. 

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> Mael wrote:
>>> WAIT. Because it seems you [Mael] are using an outdated version of gcc.
>> 
> I'll talk to some gcc developer about that.
> 
Well, what we have seen is actually a bug in gcc. 

I filed a bug report for the gcc people: 

Synopsis: [3.2/3.3/3.4 regression] gcc fails to warn about non-inlined
function

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Fri Mar 21 15:14:55 2003
State-Changed-Why:
    Confirmed. The lack of a warning is a regression introduced
    between 2.95 and 3.0. Actually inlining this function, however,
    requires unit-at-a-time compilation, which is presently
    being worked on.

So, indeed: For a function to be inlined, it has to be defined 
before calling it. Moving the functions in isosurf.cpp to the 
top (as initially suggested by mael) should be done in order to 
speed up isosurface code. 

Thanks to Mael for pointng that out initially. 

Wolfgang

Post a reply to this message

In article <3e7b8196@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> State-Changed-From-To: open->analyzed
> State-Changed-By: bangerth
> State-Changed-When: Fri Mar 21 15:14:55 2003
> State-Changed-Why:
>     Confirmed. The lack of a warning is a regression introduced
>     between 2.95 and 3.0. Actually inlining this function, however,
>     requires unit-at-a-time compilation, which is presently
>     being worked on.

For tracking the bug-id 10180 is also useful :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message