On 16/07/14 17:31, Armin Rigo wrote:
Hi,
On 15 July 2014 19:11, Elefterios Stamatogiannakis <est...@gmail.com> wrote:
Above code gets hit millions of times with different variable types. So in
our case all paths are compiled and we are linear.
Another idea that i have is the following. At startup i could sort all the
hash(types), create (in a string) a python method that does binary sorting
and eval it. Would the JIT be able to handle eval gymnastics like that?
You need to try. There are far too many variations to be able to give
a clear yes/no answer. For example, linear searches through only 6
items is incredibly fast anyway.
But here's what I *think* should occur with your piece of code (untested!):
t = type(x)
Here, in this line, in order to get the application-level type, we
need to know the exact RPython class of x. This is because the type
is not always written explicitly: a Python-level int object, for
example, is in RPython an instance of the class W_IntObject. We know
that all instances of W_IntObject have the Python type 'int'; it
doesn't need to be written explicitly as a field every time. So at
the line above, there is promotion of the RPython class of x. Right
now this is done with linear searching through all cases seen so far.
Could this be made faster with binary search or jump tables, like what
C++ compilers use to optimize switches?
I also noticed that "if" ladders checking multiple "isinstance" happen a
lot in Python's standard library. Maybe an optimization like that would
generally improve the speed of PyPy ?
If there are 5-6 different cases it's fine. (Note that RPython class
!= Python class in general, but for built-in types like int, str, etc.
there is a one-to-one correspondence.)
So at the line above, assuming that x is an instance of a built-in
type, we end up with t being a constant already (a different one in
each of the 5-6 paths).
if t is int:
...
elif t is long:
...
In all the rest of the function, the "if... elif..." are
constant-folded away. You don't gain anything by doing more
complicated logic with t.
A bientôt,
Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
