[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Also (because some of the people who might be interested are nosied on this issue), I’ve been working a bit on general performance benchmarks for our pattern-matching implementation: https://github.com/brandtbucher/patmaperformance I still need something that

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Sorry, I’ve been out on vacation this weekend. I didn’t realize that there was already a PR for this… I’m honestly not sure that it’s totally ready yet. While I absolutely agree that compiling efficient decision trees lies in our future, it certainly seems to

[issue44283] Add jump table for certain safe match-case statements

Mark Shannon added the comment: This is going in the wrong direction. Rather than add more complex instructions for use only by pattern matching, we need to simplify the individual operations and re-use existing instructions. That way pattern matching can benefit from the general performance

[issue44283] Add jump table for certain safe match-case statements

Raymond Hettinger added the comment: > How common match-case statements with literal integers? Nothing is common yet because the feature hasn't been released ;-) I suspect that if match-case were optimized for integer constants, they would be used. In discussions about case statements, the

[issue44283] Add jump table for certain safe match-case statements

Serhiy Storchaka added the comment: How common match-case statements with literal integers? I expect that in most cases such magic numbers are not used directly, but as named constants. -- nosy: +serhiy.storchaka ___ Python tracker

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: Here are some benchmarks: PS C:\Users\sween\Source\Repos\cpython2\cpython> .\python.bat -m pyperf compare_to .\main.json .\PR-26697.json Running Release|x64 interpreter... 1: Mean +- std dev: [main] 117 us +- 4 us -> [PR-26697] 122 us +- 3 us: 1.04x slower 2

[issue44283] Add jump table for certain safe match-case statements

Change by Dennis Sweeney : -- keywords: +patch pull_requests: +25282 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26697 ___ Python tracker ___ _

[issue44283] Add jump table for certain safe match-case statements

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: > Are you sure you want to do this? No, not yet. But there has been some positive feedback here, and it seems like an interesting project to prototype. :) > This optimisation is not applicable if the matched values are given symbolic > names. You would be en

[issue44283] Add jump table for certain safe match-case statements

Anders Munch added the comment: Are you sure you want to do this? This optimisation is not applicable if the matched values are given symbolic names. You would be encouraging people to write bad code with lots of literals, for speed. -- nosy: +AndersMunch _

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: Hi Brandt, I would welcome your collaboration/mentorship in whatever capacity makes sense. I sent an email to bra...@python.org from sweeney.dennis...@gmail.com. -- ___ Python tracker

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: I'm hoping we can get something close that for free by just waiting... the faster-cpython folks are working on a tagged-pointer implementation of integers as we speak. I've been looking for a new project, so I'd love to help work on this issue (if you're ope

[issue44283] Add jump table for certain safe match-case statements

Change by Kshitiz Arya : -- nosy: +Kshitiz17 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: Very interesting -- that is shorter than I thought also! If we really wanted to optimize the tar out of this, we could probably find a way to re-use just the PyDictKeysObject to find the index into a C-array of integer jump targets and not have to worry abou

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: For anyone curious, I had some free time today and took a stab at creating a minimal _frozendict type (sharing as much implementation with dict as possible) to see how difficult it would be. It was actually much simpler than I thought... just a few dozen line

[issue44283] Add jump table for certain safe match-case statements

Change by Ken Jin : -- nosy: +kj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mail

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: FWIW PEP 603 includes a graph (Figure 2) of dict.get versus hamt.get performance as the mappings grow, and it seems the hamt is roughly 1.4x slower on inputs of sizes between 10 and 1000. -- ___ Python tracker

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: > If I understand your proposal, that would mean that calling a function with a > N-case constant-pattern match would require N hashes and N insertions into a > dict (including memory allocation), followed by O(1) lookup. Wouldn't that > eliminate any hope of

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: I agree that we should benchmark for what the value of "two" should be ;) . Maybe only match statements with >=20 consecutive simple cases end up being worth it. I would assume that if "case 1, case 2, ..., case 20" are all in a row then "case 1" wouldn't be

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Hm. I’m not sure if the HAMT makes much sense. We don’t really care about efficient mutation or copies... constant-time lookups seem to be overwhelmingly the most valuable factor here. I personally think that creating some sort of hashable dict and teaching m

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: At first I thought of matches with only the int/str/None cases and then I saw the easy generalization, but yeah, each contiguous block seems better. One solution to the code hashability/lookup speed apparent dilemma: writing the equivalent of this in C: cla

[issue44283] Add jump table for certain safe match-case statements

Brandt Bucher added the comment: Seems like a good idea as long as we're careful about the implementation. I've just jotted down a few notes here: - We should probably break the table upon encountering a guard. - We probably can't get away with storing a dictionary in the code object's cons

[issue44283] Add jump table for certain safe match-case statements

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue44283] Add jump table for certain safe match-case statements

Raymond Hettinger added the comment: Big +1 from me. This would make use of match-case more compelling. -- nosy: +rhettinger ___ Python tracker ___ __

[issue44283] Add jump table for certain safe match-case statements

New submission from Dennis Sweeney : Anecdotally, a few people I've talked to have expected that match-case statements would improve performance in the same way that switch-cases sometimes do in C-like languages. While this is impossible in general without changing semantics (since, for examp