[pypy-dev] Dispatch on type

[Eleytherios Stamatogiannakis]

On 16/07/14 17:31, Armin Rigo wrote:
> Hi,
>
> On 15 July 2014 19:11, Elefterios Stamatogiannakis <estama at 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.
>