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.15:43:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1454687019.52.0.771779064581.issue21955@psf.upfronthosting.co.za>
In-reply-to
Content
> Regardless of the performance, the fastint5.patch looks like the
least invasive approach to me. It also doesn't incur as much
maintenance overhead as the others do.

Thanks.  It's a result of an enlightenment that can only come
after running benchmarks all day :)

> I'd only rename the macro MAYBE_DISPATCH_FAST_NUM_OP to
TRY_FAST_NUMOP_DISPATCH :-)

Yeah, your name is better.

> BTW: I do wonder why this approach is as fast as the others. Have
compilers grown smart enough to realize that the number slot
functions will not change and can thus be inlined ?

Looks like so, I'm very impressed myself.  I'd expect fastint3 (which just inlines a lot of logic directly in ceval.c) to be the fastest one.  But it seems that compiler does an excellent job here.

Victor, BTW, if you want to test fastint3 vs fastint5, don't forget to apply the patch from issue #26288 over fastint5 (fixes slow performance of PyLong_AsDouble)
History
Date User Action Args
2016-02-05 15:43:39yselivanovsetrecipients: + yselivanov, lemburg, rhettinger, mark.dickinson, pitrou, vstinner, casevh, skrah, Yury.Selivanov, serhiy.storchaka, josh.r, zbyrne
2016-02-05 15:43:39yselivanovsetmessageid: <1454687019.52.0.771779064581.issue21955@psf.upfronthosting.co.za>
2016-02-05 15:43:39yselivanovlinkissue21955 messages
2016-02-05 15:43:39yselivanovcreate