Brandt Bucher <brandtbuc...@gmail.com> 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 me that using *both* strategies (decision trees
and jump tables) would create the most efficient branching structure. In
effect, our control flow would be a rose tree.
In your example, Mark, we could perform the checks for the integers 1 and 2
simultaneously, right?
Or consider a slightly more complicated example (simplified from PEP 636):
match …:
case ["quit"]: …
case ["look"]: …
case ["get", obj]: …
case ["go", direction]: …
We could compile this to something like:
- Check for Sequence.
- Multi-way jump on length.
- Multi-way jump on first item.
…which looks ideal to me.
I’m also confident that the jumping ops could also be broken up into fairly
primitive instructions. A multi-way branch would just look something like:
(subject on TOS)
LOAD_CONST(<some hashable defaultdict>)
ROT_TWO
BINARY_SUBSCR
JUMP_FORWARD_TOS
…where only JUMP_FORWARD_TOS is new.
> For a sequence of integer constants, introducing the test `type(x) == int` at
> the start would allow you to convert the linear sequence of tests into a
> tree. Reducing `n` tests to `ln(n) + 1` tests.
Sorry, I’m having a bit of difficulty following this part. Is it something like
the strategy I just described?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue44283>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
