Daniel Stutzbach <stutzb...@google.com> added the comment: > The use of Py_LOCAL_INLINE is new to me since we usually use #define > instead, but this has a cleaner look to it. I am unclear on whether > all the our target compilers support an inline keyword. If you're > sure it works everywhere, that's great.
I fixed ./configure to properly set up Py_LOCAL_INLINE in Issue5553. :-) It will expand to "static inline" under both MSVC and gcc. On older compilers, it may expand to "static __inline__", "static __inline", or whatever else is needed to get the job done. As a last resort, it will expand to simply "static", but I don't know of any 32-bit (or 64-bit) compilers where that would actually happen. > Also note that this patch puts a lot of faith in branch prediction. > If some target processor doesn't support it, or has limited ability > to remember predictions, or mispredicts, then the code will be slower. I think even a limited amount of memory dedicated to branch prediction should be sufficient. There are two cases: 1) Sorting a simple type, like an int: the comparison is lightweight, and the CPU should have plenty of memory to remember which branch to take in the sorting code. 2) Sorting a complex type (i.e., calling a __lt__ method written in Python): the processor might not be able to remember which branch to take, but the performance impact will be small (as a percentage) since most of the CPU is being consumed by the comparisons. Thanks for taking the time to review this. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9915> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
