Message259678
Thanks, Serhiy,
> But I don't quite understand why it adds any gain.
Perhaps, and this is just a guess - the fast path does only couple of eq tests & one call for the actual op. If it's long+long then long_add will be called directly.
PyNumber_Add has more overhead on:
- at least one extra call
- a few extra checks to guard against NotImplemented
- abstract.c/binary_op1 has a few more checks/slot lookups
So it look that there's just much less instructions to be executed. If this guess is correct, then an LTO build without fast paths will still be somewhat slower.
> Is this just due to overhead of calling PyNumber_Add? Then we should test with other compilers and with the LTO option.
I actually tried to compile CPython with LTO -- but couldn't. Almost all of C extension modules failed to link. Do we compile official binaries with LTO? |
|
Date |
User |
Action |
Args |
2016-02-05 17:17:00 | yselivanov | set | recipients:
+ yselivanov, lemburg, rhettinger, mark.dickinson, pitrou, vstinner, casevh, skrah, Yury.Selivanov, serhiy.storchaka, josh.r, zbyrne |
2016-02-05 17:17:00 | yselivanov | set | messageid: <1454692620.46.0.253560988178.issue21955@psf.upfronthosting.co.za> |
2016-02-05 17:17:00 | yselivanov | link | issue21955 messages |
2016-02-05 17:16:59 | yselivanov | create | |
|