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.
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
