Message 379822 - Python tracker

➜

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	taleinat
Recipients	Dennis Sweeney, Zeturic, ammar2, corona10, gregory.p.smith, gvanrossum, josh.r, pmpp, serhiy.storchaka, taleinat, tim.peters, vstinner
Date	2020-10-28.08:15:30
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1603872932.12.0.104634534681.issue41972@roundup.psfhosted.org>
In-reply-to

Content
After spending quite a while setting up my dev machine for (hopefully) reliable benchmarking, I can say with a high level of certainty that the latest PR (GH-22904, commit fe9e9d9c1f1c5f98c797d19e2214d1413701f6de) runs stringbench.py significantly faster than the master branch (commit fb5db7ec58624cab0797b4050735be865d380823). See attached results. I've also run the zipf-distributed random string benchmarks provided by Dennis, with a slight addition of `random.seed(1)` in the do_timings function. Those show significant, consistent improvements on needles of length over 100, but not on shorter needles. The results are also found in the attached file. My conclusion is that the current two-way implementation is certainly better for needles of length over 100, but for shorter needles the situation is still unclear. System details: Dell XPS 9560 Intel i7-7700HQ Ubuntu 20.04 Steps taken to prepare system for performance tuning: * Enable CPU isolation for two physical cores * Disable Intel p-state driver * Disable turbo-boost * Run `pyperf system tune` * Run benchmarks with CPU pinning

After spending quite a while setting up my dev machine for (hopefully) reliable benchmarking, I can say with a high level of certainty that the latest PR (GH-22904, commit fe9e9d9c1f1c5f98c797d19e2214d1413701f6de) runs stringbench.py significantly faster than the master branch (commit fb5db7ec58624cab0797b4050735be865d380823). See attached results.

I've also run the zipf-distributed random string benchmarks provided by Dennis, with a slight addition of `random.seed(1)` in the do_timings function. Those show significant, consistent improvements on needles of length over 100, but not on shorter needles. The results are also found in the attached file.


My conclusion is that the current two-way implementation is certainly better for needles of length over 100, but for shorter needles the situation is still unclear.


System details:
Dell XPS 9560
Intel i7-7700HQ
Ubuntu 20.04

Steps taken to prepare system for performance tuning:
* Enable CPU isolation for two physical cores
* Disable Intel p-state driver
* Disable turbo-boost
* Run `pyperf system tune`
* Run benchmarks with CPU pinning

History
Date	User	Action	Args
2020-10-28 08:15:32	taleinat	set	recipients: + taleinat, gvanrossum, tim.peters, gregory.p.smith, vstinner, pmpp, serhiy.storchaka, josh.r, ammar2, corona10, Dennis Sweeney, Zeturic
2020-10-28 08:15:32	taleinat	set	messageid: <1603872932.12.0.104634534681.issue41972@roundup.psfhosted.org>
2020-10-28 08:15:32	taleinat	link	issue41972 messages
2020-10-28 08:15:31	taleinat	create