Feature Request: nontrivial functions and vtable optimizations

[Craig Black]

"Jb" <jb at nowhere.com> wrote in message news:g843q6$104a$1 at digitalmars.com...
>
> "Craig Black" <craigblack2 at cox.net> wrote in message 
> news:g82rj4$1hqn$1 at digitalmars.com...
>>>
>>> The speedup you get from this is the inlining of the function, *not* the 
>>> getting rid of the function pointer lookup. It still requires a lookup 
>>> in the class info and a conditional branch to check that the "inlined 
>>> function" is the correct match for the speculated object.
>>>
>>> That will still cost a whole pipline of cycles if wrongly predicted.
>>
>> You may be right in some cases.  Profile to be sure.  But experience has 
>> taught me to be wary of function pointer invokations, even on modern 
>> CPU's. If you want to believe that there is never a penalty for function 
>> pointer invokation go right ahead.  After all, it's only two instructions 
>> right? Must be real fast. ;)
>
> I'm not saying there's no penalty, im saying it's a penalty you cant 
> escape if you want virtual functions.
>
> Function pointer invocations == conditional branches as far as modern 
> branch predictors are concerned. You dont gain anything by replacing the 
> former with the later.

I thought you were wrong about this so I did a micro-benchmark and it 
indicates that you are correct.  With only 1 branch the performance of an if 
statement was exactly the same as a function pointer invokation.  Function 
pointer invokations ended up being roughly 50% faster than a sequence of 
if-elses.  I guess I stand corrected.

-Craig