Marc-Andre Lemburg added the comment: On 04.02.2016 07:02, Yury Selivanov wrote: > Attaching a second version of the patch. (BTW, Serhiy, I tried your idea of > using a switch statement to optimize branches > (https://github.com/1st1/cpython/blob/fastint2/Python/ceval.c#L5390) -- no > detectable speed improvement).
It would be better to consistently have the fast_*() helpers return -1 in case of an error, instead of -1 or 1. Overall, I see two problems with doing too many of these fast paths: * the ceval loop may no longer fit in to the CPU cache on systems with small cache sizes, since the compiler will likely inline all the fast_*() functions (I guess it would be possible to simply eliminate all fast paths using a compile time flag) * maintenance will get more difficult In a numerics heavy application it's like that all fast paths will trigger somewhere, but those will likely be better off using numpy or numba. For a text heavy application such as a web server, only few fast paths will trigger and so the various checks only add overhead. Since 'a'+'b' is a very often used instruction type in the latter type of applications, please make sure that this fast path gets more priority in your patch. Please also check the effects of the fast paths for cases where they don't trigger, e.g. 'a'+'b' or 'a'*2. Thanks, -- Marc-Andre Lemburg eGenix.com ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21955> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
