Optimize round_size for rehashing

[jneb]

BPO	42673
Nosy	@jneb, @serhiy-storchaka, @jstasiak, @akulakov
PRs	bpo-42673 prevent branch misprediction in round_size (used in rehash) #23833

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-12-23.23:20:55.583>
created_at = <Date 2020-12-18.09:35:27.357>
labels = ['interpreter-core', '3.10', 'performance']
title = 'Optimize round_size for rehashing'
updated_at = <Date 2021-12-23.23:20:55.580>
user = 'https://github.com/jneb'

bugs.python.org fields:

activity = <Date 2021-12-23.23:20:55.580>
actor = 'andrei.avk'
assignee = 'none'
closed = True
closed_date = <Date 2021-12-23.23:20:55.583>
closer = 'andrei.avk'
components = ['Interpreter Core']
creation = <Date 2020-12-18.09:35:27.357>
creator = 'jneb'
dependencies = []
files = []
hgrepos = []
issue_num = 42673
keywords = ['patch']
message_count = 6.0
messages = ['383291', '383294', '383302', '383991', '384017', '409112']
nosy_count = 4.0
nosy_names = ['jneb', 'serhiy.storchaka', 'jstasiak', 'andrei.avk']
pr_nums = ['23833']
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue42673'
versions = ['Python 3.10']

[jneb]

There's a trivial optimization in the round_size in hashtable.c:
a loop is used to compute the lowest power of two >= s,
while this can be done in one step with bit_length.
I am making a pull request for this.

[serhiy-storchaka]

Do you have any benchmarks?

[jstasiak]

I'd be especially curious about branch (mis)prediction stats before and after applying this patch – including such information seems necessary in a patch that's about optimization.

[serhiy-storchaka]

Since no benchmarking data was provided, I suggest to close this issue. We do not accept optimization changes without evidences of performance boost.

[jneb]

Harsh, but fair.
I'll do a better job next time!

Op di 29 dec. 2020 13:42 schreef Serhiy Storchaka <report@bugs.python.org>:

Serhiy Storchaka <storchaka+cpython@gmail.com> added the comment:

Since no benchmarking data was provided, I suggest to close this issue. We
do not accept optimization changes without evidences of performance boost.

----------
status: open -> pending

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue42673\>

---

[akulakov]

Closing as it sounds like OP agreed to it in the last msg; and no benchmarking was provided.