Why Strings as Classes?

Jb jb at nowhere.com
Tue Aug 26 07:56:14 PDT 2008


"superdan" <super at dan.org> wrote in message 
news:g912vh$mbe$1 at digitalmars.com...
> Jb Wrote:
>
>>
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message
>> news:g90iia$2jc4$3 at digitalmars.com...
>> > Yigal Chripun wrote:
>> >> a) people here said that a virtual call will make it slow. How much
>> >> slow? how much of an overhead is it on modern hardware considering 
>> >> also
>> >> that this is a place where hardware manufacturers spend time on
>> >> optimizations?
>> >
>> > Virtual function calls have been a problem for hardware optimization.
>> > Direct function calls can be speculatively executed, but not virtual 
>> > ones,
>> > because the hardware cannot predict where it will go. This means 
>> > virtual
>> > calls can be much slower than direct function calls.
>>
>> Modern x86 branch prediction treats indirect calls the same as 
>> conditional
>> branches. They get a slot in the branch target buffer, so they do get
>> speculatively executed. And if correctly predicted it's only a couple of
>> cycles more costly direct calls.
>>
>> See the thread "Feature Request: nontrivial functions and vtable
>> optimizations" about 2 weeks ago.
>>
>> I cited the technical docs and a few doubters ran benchmarks, which 
>> proved
>> that virtual methods are not as evil as many people think. In fact they 
>> are
>> no more evil than a conditional branch.
>
> you're right. but direct calls don't speculate. they don't need 
> speculation because they're
>direct jump. so they are loaded straight into the pipeline.
>
> walt was right but used the wrong term.

Walter said "the hardware cannot predict where a virtual call will go".

It does in fact predict them, and speculatively execute them, and as pretty 
much any bechmark will show it gets it right the vast majority of the time. 
(On x86 anyway.)

That's what I was saying. 





More information about the Digitalmars-d mailing list