This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Inlining functions vs. inlining member functions as templates


Hi Eljay and others, just a few concluding remarks.

On Tuesday 17 May 2005 13:55, Eljay Love-Jensen wrote:
> Hi Peter,
>
> >Why doesn't the compiler manage to do the same thing for the function
> > version, that it apparently does between -O1 and -O3 for the struct
> > version?
>
> It's a pretty tall order.  You are saying "Ignore what I explicitly
> programmed the function to do, and inline what I specified as a function
> pointer parameter because it will be more efficient".
>

Well, first I wasn't really thinking so much about what I was _actually_ 
telling the function (or the compiler) to do. For some reason I had a feeling 
that the function version should be faster because no class is involved. 

With a bit of thinking and experimenting I understood the function pointer 
part, but wasn't sure that that was all. The last optimization step didn't 
seem that difficult when the pointer was already gone. That's why I asked 
here.

> .....

>  Since I come from an assembly language (6502,
> 680x0) background, I think of C as a really neat macro assembler.  (But I
> think of C++ as an object oriented language moreso than a excellent macro
> assembler; go figure.)
>

I am totally on the OO side. My motivation for the function was (as I said 
above) that somehow I thought it should be faster in a very critical place (4 
nested loops). Oh, and the implementation is completely hidden from users of 
the library I'm working on, of course.

> And that School B is the kind of optimization that I expect out of a Java
> compiler *AND* a continuously optimizing/re-optimizing JIT JVM.
>
> You can get some of the School B benefits in School A, if you have a
> feedback mechanism in your development process to feed profiling
> information back into the compilation process.  (Or if your C/C++ code (or
> tokenized binary thereof) was interpreted live instead of compiled.)  But
> even then, I really wouldn't expect* the compiler to ignore what you told
> it to do because some impressive wholistic optimization analysis technique.
>
> * Not that it's impossible; just not what I'd expect.  I'd be pleasantly
> surprised if it did the kind of optimization that even changes function
> signatures to remove (optimize away) parameters (such as the function
> pointer parameter specified in your example)!  Wow!
>

I _am_ very impressed with the optimizations gcc4.0.x does. The purpose of 
this question was not to criticize what the compiler does (or does not). I 
just wanted to be sure never to fall into the same trap again. So I wanted to 
fully understand what was happening.

>From what I learned I draw the conclusion that the optimization I thought of 
could be done but that maybe it should not be done. And it should definitely 
not be expected (more than is usual for optimizations).

> Sincerely,
> --Eljay

Thanks alot for the detailed answer to my question. I'll be staying away from 
the function pointers now _and_ know why. 

Best regards,
Peter


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]