This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients Yury.Selivanov, casevh, josh.r, lemburg, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, skrah, vstinner, yselivanov, zbyrne
Date 2016-02-05.17:16:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1454692620.46.0.253560988178.issue21955@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2016-02-05 17:17:00yselivanovsetrecipients: + yselivanov, lemburg, rhettinger, mark.dickinson, pitrou, vstinner, casevh, skrah, Yury.Selivanov, serhiy.storchaka, josh.r, zbyrne
2016-02-05 17:17:00yselivanovsetmessageid: <1454692620.46.0.253560988178.issue21955@psf.upfronthosting.co.za>
2016-02-05 17:17:00yselivanovlinkissue21955 messages
2016-02-05 17:16:59yselivanovcreate