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
--
https://mail.python.org/mailman/listinfo/python-list
