[issue28397] Faster index range checks

Serhiy Storchaka added the comment: See also PR 9784 where Raymond shown assempler code generated for two variants. There is the similar difference on 64-bit platform with GCC 7.3: $ gcc -O3 -o issue28397 issue28397-2.c $ time ./issue28397-2 0 real0m2,740s user0m2,739s sys 0m0,0

[issue28397] Faster index range checks

Change by Sergey Fedoseev : -- nosy: +sir-sigurd ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue28397] Faster index range checks

Change by Raymond Hettinger : -- pull_requests: +9170 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue28397] Faster index range checks

Serhiy Storchaka added the comment: Raymond extracted his optimization into separate function and commented it. -- ___ Python tracker ___

[issue28397] Faster index range checks

STINNER Victor added the comment: Serhiy Storchaka: "I opened this issue because this optimization already was applied to deque (issue23553)" Ah, change 1e89094998b2 written by Raymond Hettinger last year, Raymond who wrote (msg278397): "Don't change the code in the collections module. While

[issue28397] Faster index range checks

Serhiy Storchaka added the comment: Unlikely this optimization have measurable affect on benchmarks. I opened this issue because this optimization already was applied to deque (issue23553), and it is easy to write a script for applying it to all code. But since there are doubts about this opti

[issue28397] Faster index range checks

STINNER Victor added the comment: Serhiy: "The latter form generates simpler machine code." Since this issue is an optimization, can you please provide results of Python benchmarks? Maybe run the performance benchmark suite? I just released performance 0.3 with new benchmarks and less bugs! ;-

[issue28397] Faster index range checks

Stefan Krah added the comment: On 64-bit Linux there's no difference: $ ./usr/bin/gcc -O3 -o issue28397-2 issue28397-2.c $ time ./issue28397-2 0 real0m2.486s user0m2.424s sys 0m0.014s $ time ./issue28397-2 1 real0m2.433s user0m2.422s sys 0m0.008s Also, most of the t

[issue28397] Faster index range checks

Марк Коренберг added the comment: $ gcc -O3 -DDOIT=doit ./zzz.c -o zzz && time ./zzz real0m1.675s user0m1.672s sys 0m0.000s $ gcc -O3 -DDOIT=doit2 ./zzz.c -o zzz && time ./zzz real0m1.657s user0m1.656s sys 0m0.000s

[issue28397] Faster index range checks

Serhiy Storchaka added the comment: In your example functions are inlined. If prohibit inlining, the second function is faster. $ gcc -O3 -o issue28397 issue28397-2.c $ time ./issue28397 0 real0m8.097s user0m7.992s sys 0m0.012s $ time ./issue28397 1 real0m5.467s user0m5.4

[issue28397] Faster index range checks

Stefan Krah added the comment: That matches my results as well: -O2 gives about the same speed, with -O3 doit() has a huge advantage. I'm not sure this is an optimization at all. -- ___ Python tracker __

[issue28397] Faster index range checks

Марк Коренберг added the comment: Without optimisation in compiler (-O0) speed is the same. -- ___ Python tracker ___ ___ Python-bugs-

[issue28397] Faster index range checks

Марк Коренберг added the comment: $ gcc --version gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609 -- ___ Python tracker ___ ___ Pyt

[issue28397] Faster index range checks

Марк Коренберг added the comment: -O2 -- the same speed too! -O3 really helps. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue28397] Faster index range checks

Марк Коренберг added the comment: oh shidoit() i.e. return index < 0 || index >= nitems; is faster! -- ___ Python tracker ___ __

[issue28397] Faster index range checks

Марк Коренберг added the comment: Much more conveniet way is to use unsigned variables in appropriate places. -- ___ Python tracker ___ __

[issue28397] Faster index range checks

Stefan Krah added the comment: Which version is faster in your tests? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue28397] Faster index range checks

Марк Коренберг added the comment: I have tested. performace differs in about of two times. gcc -O3 0.22 nanoseconds per comparison. vs 0.58 nanoseconds per comparison. Does it cost a time that we spent to discuss here ? -- nosy: +mmarkk ___ Python t

[issue28397] Faster index range checks

Stefan Krah added the comment: The difference in favor of doit() is even more pronounced with this loop (also sorry for the uninitialized variable, but that does not make a difference for benchmarking): = for (i = 0; i < 1; i++) { for (j = 0; j < 1

[issue28397] Faster index range checks

Stefan Krah added the comment: In the following program, with gcc-5.3 doit() is significantly faster than doit2() in 64-bit Linux: #include int doit(int64_t index, int64_t nitems) { return index < 0 || index >= nitems; } in

[issue28397] Faster index range checks

Stefan Krah added the comment: The same applies to memoryview.c and _testbuffer.c -- I doubt that there's any measurable speed benefit and the clarity is reduced (I also don't want macros there). -- ___ Python tracker

[issue28397] Faster index range checks

Stefan Krah added the comment: Serhiy, could you please take out _decimal.c? I thought we had been through that before. :) :) :) -- nosy: +skrah ___ Python tracker ___ _

[issue28397] Faster index range checks

Raymond Hettinger added the comment: Don't change the code in the collections module. While semantically valid, the change obfuscates the code. The meaning of maxlen < 0 is that there is no maximum length. I don't want this test hidden; otherwise, I would have changed it long ago as was don

[issue28397] Faster index range checks

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45035/check_index.cocci ___ Python tracker ___ ___ Python-bugs-list maili

[issue28397] Faster index range checks

New submission from Serhiy Storchaka: The expression for testing that some index is in half-open range from 0 to limit can be written as index >= 0 && index < limit or as (size_t)index < (size_t)limit The latter form generates simpler machine code. This is idiomatic code, it is used