Predefined Version expansion

Dave Dave_member at pathlink.com
Wed Apr 4 10:46:23 PDT 2007


Don Clugston wrote:
> Daniel Keep wrote:
>>
>> Walter Bright wrote:
>>> Don Clugston wrote:
>>>> Yes, it's possible to detect the CPU type at runtime, but the
>>>> performance penalty is appalling for very short functions.
>>> If it is, then one should put the switch at an enclosing level.
>>
>> Out of interest, which is faster: a branch at the start of a function
>> (say, just a comparison with a bool), or using function pointers that
>> are set up to point to the correct implementation at start-up?
>>
>>     -- Daniel
> 
> I suspect the bool comparison would be *much* quicker, since the branch 
> is trivially predictable, and will only cost a single clock cycle. 
> AFAIK, it's only in the past two years that any CPUs have had branch 
> prediction for indirect branches. OTOH, the version involving branches 
> would probably be less code-cache efficient.
> The fastest option would be to patch the CALL instructions directly, 
> just as a linker does. DDL will probably be able to do it eventually.

I've seen this type of thing used in Intel compiler generated code to good effect, and w/o really 
any adverse performance that I'm aware of.

Just a thought for D -- add a global CPU type to the D standard runtime that is set during 
initialization (i.e.: in Dmain) that can be used by user code like BLADE and by the compiler itself 
for (future) processor determined optimization branches.

Actually, I'm kind-of surprised one isn't there already (or is it?).

- Dave



More information about the Digitalmars-d mailing list