Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Wed Jul 20 2005 02:48 am

Flavius Vespasianus wrote:
> Brian <brian@rohan.sdsu.edu> wrote in news:dbj5f7$rdv$1@gondor.sdsu.edu:
> > Getter and setter functions are another simple example of what seems
> > to be waste.  The method call works like this.  The existing register
> > states are pushed onto the stack.  The call is made.  The getter
> > method returns a simple value on the stack.  The call is returned.
> > The registers are popped.  That must be about 20 instructions for
> > what might only take one, a simple memory read, or better yet, a
> > register read.
>
> Calling a non-virtual function is no slower than calling a C function. If
> the function is defined inline, compiler has no need for the call stack.
>
> And I can't imagine any compiler implementing a set function that could
> be implemented in one instruction having 20 push and pops.

Calling a virtual function may be though.  For example, the code must:-
<add the offset of the function in question to the base vtable pointer>
<from that address load the function pointer>
<save caller saved registers on the stack>
<construct call frame for the passed args, possibly not needed>
<call the function>
<make a stack frame>
<return from the function>
<restore caller saved registers>

It likely won't be this complex, but it could be.

> >
> > What happens if a getter or setter is right in the middle of a
> > tight loop?  Let's say the loop has 200 instructions.  All of a
> > sudden the loop is 10% less efficient.
>
> The alternative, in the absence of OO is a large case statement; hardly
> efficient either.

What the OP is talking about is using getter and setter functions
rather than global variables.  So, in this case a load from memory
could be used instead.

> > Anyway, those are some of the things that kind of nag at me.
> > I think it's a safe statement to say C can beat any OO compiled
> > program pound for pound given the same programmer skill and
> > adherence to language goals.
>
> I once reviewed a book manuscript for a publisher, the author of which
> would entirely agree with you -- people who think they can code faster
> than the compiler can optimize. The book consisted of all kinds of tricks
> in C to make your code faster.
>
> I benchmarked all of his examples and EVERY one of his optimization
> tricks resulted in slower code.

That individual may not have been very skilled in this area.  But such
tricks do exist.  Paul Hsieh and Tim Rentsch who post here for example
know a lot about writing fast code.

> > Does everyone drop into C for critical code?
>
> Never. C is a horrible programming language has caused the software
> industry decades of suffering.

Interesting, personally I think C is a beautiful programming language.
There are many better languages today, the problem is that they are not
so well known.

.