[lkml]   [2012]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups + docs
    On 02/21/2012 11:25 PM, Ingo Molnar wrote:
    > There is a fundamental assymetry, and intentionally so. You
    > *really* have to think what the common case is, and make sure
    > the build defaults to that. It's not the end of the world to
    > have it flipped over, but there's costs and those costs are
    > higher even in the branch path than a regular
    > likely()/unlikely().

    No, not really -- it's still an unconditional branch, which means you
    will not tax the branch predictor in any way and which can be followed
    by the front end without taking a speculation hit. So although there is
    an out-of-line penalty -- which you hit for any conditional, after all
    you can only have *one* piece of code which is straight line -- it
    should be less than for a normal conditional branch.

    > So you are rather wrong about your expectations - I think that
    > is one more piece of evidence that the naming was less than
    > optimal.
    >> So the key aspect of this is the staticness of the
    >> conditional, NOT the degree of bias of the branch. Hence my
    >> past insistence on the "static_branch" name (rather than
    >> "jump_label")... the branch part can be omitted, as an
    >> implementation detail, but the staticness of it is its
    >> absolutely key defining characteristic.
    > I don't think you understand this facility as well as you think
    > you do.

    Uh, no, I do... see the above, but combine that of course with the sheer
    astronomical cost of flipping the conditional.


    H. Peter Anvin, Intel Open Source Technology Center
    I work for Intel. I don't speak on their behalf.

     \ /
      Last update: 2012-02-22 08:39    [W:0.030 / U:1.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site