Micro-optimize list index range checks

[rhettinger]

Old code

_list_item:
    testq   %rsi, %rsi 
    js  L282
    cmpq    %rsi, 16(%rdi)
    jg  L283
    ...
L283:
    movq    24(%rdi), %rax
    movq    (%rax,%rsi,8), %rax
    addq    $1, (%rax)
    ret

New code

_list_item:
    cmpq    16(%rdi), %rsi
    jb  L282
    ...
L282:
    movq    24(%rdi), %rax
    movq    (%rax,%rsi,8), %rax
    addq    $1, (%rax)
    ret

[serhiy-storchaka]

Is not this like bpo-28397?

[pablogsal]

It would be interesting to run Linux perf on some representative examples to understand how the function call is affecting cache misses, references and branch predictions. (See #6493 as an example).

[vstinner]

I'm not sure that the behaviour is well defined in C. I fear that it's Undefined Behaviour. @benjaminp @gpshead: What do you think ?

[vstinner]

If it's well defined, why should we hack such micro optimization? Why compilers would not implement the optimization themself?

[sir-sigurd]

I think because they don't know that Py_SIZE(op) is non-negative.

[serhiy-storchaka]

It is well defined. It is used for example in the STL implementations.

But there was not found any difference in microbenchmark results on 64-bit platforms in previous discussion in bpo-28397.

[gpshead]

Regardless of if this change is measurable, i like the way the code looks afterwards, getting rid of the repeated verbose i < 0 || i >= Py_SIZE(spam) everywhere. so +1 from me.

[gpshead]

Why not just define this as taking two size_t parameters instead of doing the casting below. The casts then happen implicitly at all call sites.