lkml.org 
[lkml]   [2003]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] oops_in_progress is unlikely()
    On Wed, 10 Sep 2003, Jamie Lokier wrote:

    > Richard B. Johnson wrote:
    > > I would guess that the compiler output might be:
    >
    > Your guess is incorrect.
    >
    > > You are always going to take an extra jump in one execution
    > > path after the function, and you will take a conditional jump
    > > before the function call in the other execution path. So, you
    > > always have the "extra" jumps, no matter.
    >
    > That is not true. The "likely" path has no taken jumps.
    >

    Absolutely, positively, irrefutably wrong! Any logical operation
    with any real processor can only result in a jump upon condition. The
    path not taken will always require a jump around the code that
    handled the jump upon condition unless the code exists at
    the end of a procedure where a 'return' will suffice. Period. There
    is discussion if you don't understand this. If you insist upon
    taking exception to everything I say, without even reading what
    I say, then you are wasting a lot of energy.

    All real processors make jumps based upon the preceeding logical
    operation, i.e., if equal, if less, if greater, if true. With
    Intel, you have the following construct:
    After the conditional test, everybody has to execute from label
    more_code:



    cmpl $1, %eax
    jz 1f
    jc 2f
    call do_default
    jmp more_code
    1: call do_something_if_equal
    jmp more_code
    2: call do_something_if_less
    more_code:

    In every case, one has to jump around code for other execution paths
    except the last, where you have to jump on condition anyway. There
    is no free liunch, and the straight-through route, do_default
    uas just as many jumps as the last.


    > Think about the code again.
    > How would you optimise it, if you were writing assembly language yourself?
    >

    I did. And I do this for a living. And, after 30 years of this shit
    they still haven't fired me. Learn something. I'm pissed.

    > (In more complex examples, another factor is that mis-predicted
    > conditional jumps are much slower than unconditional jumps, so it is
    > good to favour the latter in the likely path).
    >

    Show me the money. With Intel, the testing of the condition, existing
    in the flags, requires an instruction, unconditional or not.

    > -- Jamie
    >

    Cheers,
    Dick Johnson
    Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
    Note 96.31% of all statistics are fiction.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:48    [W:3.628 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site