Re: [PATCH v2 00/16] Speeding up DEFVAR_PER_BUFFER

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yes, it's probably a trade-off.  My guess is that the extra overhead of
>> BVAR will not be significant, but benchmarking is the only way to know
>> for sure.  (Indeed, it's possible things will speed up by removing the
>> metadata, which reduces the size of the working set and lets more things
>> stay in cache)
>
> Maybe one way to figure it out is to magnify the impact: add extra
> slowdown code to BVAR to make sure the slowdown is noticeable.
> This might point to the place where a performance impact may be
> measurable, or it might make it obvious that the impact is negligible.
>
>> Well, with a completely naive static branch-predictor which assumes the
>> Qunbound branch will never be taken, there will be no overhead for
>> fields which are never Qunbound, namely non-DEFVAR_PER_BUFFER fields and
>> permanent-buffer-locals.  We could encourage that prediction by marking
>> the Qunbound branch with an "unlikely()" macro using GCC's
>> __builtin_expect.
>
> While this might work for some vars, I suspect that it could be
> detrimental for some.
>
>> It's probably prematurely low-level for me to talk about such things
>> right now though - benchmarking is the only way to know.
>
> 100% agreement.  And modern branch predictors are quite sophisticated so
> I expect they'll do a much better job than any hint we may be able
> to provide.

Is not possible to provide hints to the branch predictor.  The
__builtin_expect is used only to hint GCC to reorder basic blocks so
that the most likely execution path is going to be sequential, this to
maximize i-cache efficiency.  I doubt a single __builtin_expect will
have a measurable impact here.

  Andrea