Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>>>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
>>> A different op would be a better performance win. Even those sections
>>> that didn't want the check has to pay for it.
>
>GB> That may not be completly true. You would in effect be increasing the
>GB> size of code for perl itself. Whether or not it would be a win would
>GB> depend on how many times the extra code caused a cache miss and a fetch
>GB> from main memory.
>
>GB> As Chip says, human intuition is a very bad benchmark.
>
>Does the cache hit/miss depend on the nearness of the code
To some extent.
>or simply
>on code path?
That can have an effect too. not just caches but pre-fetch and branch
prediction mess here as well.
>Obviously having the checked version be a wrapper of
>the base op and near it on the same page would be a VM win.
Caches work well with small-ish linear-ish hotspots that keep being re-used.
When access pattern does not follow that pattern things get (gradually) worse.
How gradual and how -ish depends on cache architecture which is
fun, often proprietary and off-topic ;-) - I can write a quick "turorial"
e-mail if there is general interest (and I must have a biblography somewhere
at work).
--
Nick Ing-Simmons
