Re: inline failure with union POD
On Mar 10, 9:01 pm, "andrew_n...@yahoo.com" <andrew_n...@yahoo.com>
wrote:
My mistake. I didn't have optimizations all the way up to max. It
works perfectly if I use -Ob2 meaning "inline any available".
The reason that its a bottleneck is that I'm writing a VM for a
scripting language, and if someone were to benchmark integer
arithmetic, it would be 50% slower without the inline, as I've already
discovered.
Do such benchmarks reflect actual use? If not, they're
irrelevant.
By the way, I have another posting about subrefing. I want to
give more information here:
struct EObject {
int refcnt;
virtual void Free () = 0;
void SubRef ()
{
if (--refcnt == 0)
Free();
}
};
Lets say I have an EArray which is a fully derived EObject. Then, in
the following:
main {
EObject* o = GetMyArrayPtr(); // widen
o->SubRef(); // does NOT inline!!!
EArray* ar = static_cast<EArray*>(o); // narrow
ar->SubRef(); // does inline!!!
}
There seems to be no reason why the compiler would inline the
fully derived pointer but not inline the base class pointer
when calling SubRef().
It looks a bit strange, yes. On the other hand, SubRef contains
a virtual function call. Perhaps the compiler considers that
the cost of that call will outweigh the non-virtual call to
SubRef. On the other hand, I wonder how it knows that EArray
really is the most derived type (so that the call isn't virtual
when it inlines).
Not knowing the compiler, and how it generates code, it's hard
to tell. (Most compilers today use profiler output to control
optimization. Maybe the profiler output you've given it doesn't
correspond to typical cases.)
This is so concerning that I may have to use macros for all
my SubRefs() or their equivalent. Isn't that terrible. The problem
with a macro is that it would have to use another temp variable which
may not be a register.
My overall complaint is that inlining means to me, just kind of macro
expand the function.
That's not what it means. There are, for example, compilers
that can do a better job of it than the programmer. (They
aren't common, but they do exist.) More generally, it is a
*hint* to the optimizer.
Why should inlined functions ever not be
inlined, other than being too big?
Any number of reasons.
Isn't this the biggest
optimization that a compiler can make?
Certainly not. For anything but the simplest functions, it's
usually insignificant. The cases where it is most significant
are generally those where it allows further optimizations; e.g.
a function which just returns a constant, where inlining then
allows further constant propagation.
It sure seems to be the most
important based on my profiling.
Are you sure? Or are you measuring some other effect? (I don't
know how you can separate the time necessary for the call from
the time spent in the function itself with the profiler I use.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]