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.