[issue25106] Hash computation speedup for {buffer, string, unicode}object

Gregory P. Smith added the comment: Reopen this if you find a reproducible way for this patch to prove useful. -- resolution: -> rejected status: open -> closed ___ Python tracker _

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Serhiy Storchaka added the comment: Ping. -- status: pending -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Changes by Brett Cannon : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Changes by Jelle Zijlstra : -- nosy: +Jelle Zijlstra status: pending -> open ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Changes by Brett Cannon : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Alecsandru Patrascu added the comment: Please hold this patch for a while, while I analyze the received feedback. -- ___ Python tracker ___ __

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Changes by Skip Montanaro : -- nosy: +skip.montanaro ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Maciej Fijalkowski added the comment: I find numbers really hard to believe. It would mean that over 40% of django templates is string hashing (assuming 2x speedup) which really sounds unbelievable. In fact in PyPy I never found string hashing to be significant while I would expect PyPy to ha

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Gregory P. Smith added the comment: Testing this on a host with a fixed frequency and mostx background tasks disabled I cannot reproduce the speedups you list. I see no significant change on most of them and a 6% slowdown on json_load and a 1-4% slowdown on regex_v8 (not sure if those are in

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Gregory P. Smith added the comment: attaching an updated patch. fwiw, in my own quick tests i'm not seeing a performance difference on the benchmark suite. but i am not trying to run it in such an isolated quiet machine locked freq. environment. it is still a good idea regardless. _some_ c

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Brett Cannon added the comment: Assuming Benjamin doesn't object I don't think we need to explicit ask Guido. He made his feelings quite clear about allowing backports of performance improvements that already exist in Python 3 and have been battle-tested. Having said that, I hope Intel is also

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Serhiy Storchaka added the comment: The code for str and buffer can be shared as _Py_HashBytes() (as in 3.4+). Also please add comments in the switch block as in 3.4+. Should we ask Guido for granting backport exemption for this optimization? -- nosy: +benjamin.peterson __

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Chris Angelico added the comment: +1 for anything that makes Python faster with provably no semantic changes. -- ___ Python tracker ___ __

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Alecsandru Patrascu added the comment: Yes, it doesn't break the compatibility with existing applications. To make sure, we tested it in various scenarios and workloads. -- ___ Python tracker _

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Brett Cannon added the comment: If this is applying something we already did in Python 3 and it doesn't break compatibility then this should fall under the same sort of backport exemption that Guido granted for the eval loop performance enhancements that Intel did a couple months back. --

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Alecsandru Patrascu added the comment: This patch is not applicable to Python 3, as it already has a better hash function and has the same unrolling technique applied. As Brett well observed, it is a backport of an optimization technique used in Python 3, applied to the existing hash function

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Brett Cannon added the comment: Is this applicable to Python 3 at all? From Serhiy's comment I think this might be a backport of a technique already used there, but it's not entirely clear as Alecsandru didn't say why there wasn't a 3.6 patch. -- nosy: +brett.cannon __

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Alecsandru Patrascu added the comment: I've submitted a more compact version of the previous code (hash8-v02.patch) -- ___ Python tracker ___

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40460/hash8-v02.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Alecsandru Patrascu added the comment: Yes, sure it can be implemented in smaller space, as Serhiy and Chris well pointed out. I submitted the 01 version like that just to be clear that I don't want to re-implement a new hash computing value and just unroll the loop in the existing one. I will

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Serhiy Storchaka added the comment: > Or at very least, can fallthrough be used in the switch block, so there > aren't 7+6+5+4+3+2+1 copies of the same line? It is how _Py_HashBytes is implemented in 3.4+. -- title: Hash computation speedup for {buffer,string,unicode}object -> Hash com

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Chris Angelico added the comment: Or at very least, can fallthrough be used in the switch block, so there aren't 7+6+5+4+3+2+1 copies of the same line? -- Not a C performance expert -- -- ___ Python tracker _

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Chris Angelico added the comment: Hmm. Is Duff's Device a valid construct for CPython? It'd shorten this a lot... -- nosy: +Rosuav ___ Python tracker ___

[issue25106] Hash computation speedup for {buffer, string, unicode}object

STINNER Victor added the comment: > Python 2.7 is closed for adding new features. Python 3.4+ uses different code > for calculating hashes. The code doesn't modify the hash function. It's a common loop unroll optimization technique. Since the optimization can be seen on real world benchmark,

[issue25106] Hash computation speedup for {buffer, string, unicode}object

Serhiy Storchaka added the comment: Python 2.7 is closed for adding new features. Python 3.4+ uses different code for calculating hashes. -- nosy: +serhiy.storchaka ___ Python tracker _

[issue25106] Hash computation speedup for {buffer, string, unicode}object

New submission from Alecsandru Patrascu: Hi All, This is Alecsandru from Server Scripting Languages Optimization team at Intel Corporation. I would like to submit a patch that improves the performance of the hash computation code on stringobject, bufferobject and unicodeobject. As can be see