Python and the need for speed

[bartc]

On 19/04/2017 00:19, Gregory Ewing wrote:
> bartc wrote:

>> Another optimisation for something like ADD, was to to check for very
>> common types such as INT, and deal with those locally.
>
> And then you're on the path to writing a JIT compiler. If you
> can identify such cases, you might as well generate machine
> code for them.

No, the fast code path to be executed already exists when writing the 
interpreter.

The decision to use it would be done on a per-byte-code basis.

Rather a crude way of speeding things up. If you're ADDing something 
that isn't two ints or is just a bit too complex (int+float for 
example), then that would slow down because of the extra check for two ints.

Where it gets more JITish is if it identifies that a sequence of 
byte-codes can be handled by dedicated code synthesised at runtime, 
which can also have hard-coded operands rather than picking them up from 
the byte-code stream.

But this can still be done during an initial pass. This is some way from 
the very ambitious tracing JITs that people are up to now.

(I'm not going down route because I specialise in doing things the easy 
way.)


-- 
bartc