[Python-ideas] Bytecode JIT

Soni L. fakedme+py at gmail.com
Sun Jul 2 09:32:41 EDT 2017



On 2017-07-02 02:41 AM, Steven D'Aprano wrote:
> On Sat, Jul 01, 2017 at 07:52:55PM -0300, Soni L. wrote:
>>
>> On 2017-07-01 07:34 PM, Victor Stinner wrote:
>>> Let's say that you have a function "def mysum (x; y): return x+y", do
>>> you always want to use your new IADD instruction here? What if I call
>>> mysum ("a", "b")?
>>>
>>> Victor
>> Let's say that you do. Given how short it is, it would just get inlined.
>> Your call of mysum ("a", "b") would indeed not use IADD, nor would it be
>> a call. It would potentially not invoke any operators, but instead get
>> replaced with "ab".
> What you are describing sounds more like the output of a keyhole
> optimizer that folds constants, only extended to look inside functions.
> I expect that it would have to be a VERY clever optimizer, since it
> would have to do a complete whole-of-program static analysis to be sure
> that mysum has not been replaced, shadowed or redefined by the time it
> is called.

Runtime. Not static. This is the same kind of stuff LuaJIT (and any 
other JIT) does.

>
> I won't say that is outright impossible, but it would be *extremely*
> hard to do something like that at compile time.
>
>   
>> When you have a tracing JIT, you can do away with a lot of overhead. You
>> can inline functions, variables, do away with typechecks, and many other
>> things. This holds true even if that JIT never emits a single byte of
>> machine code.
> What you are describing sounds more like an "Ahead Of Time" (AOT)
> compiler to me. Especially the part about doing away with typechecks. As
> far as I know you can really only do away with typechecks or other
> guards if you know ahead of time (at compile time) what the types of
> values are, and that requires static typing.
>
>

You can do that at runtime with a JIT and flushing the JIT cache when 
your assumptions (guards) change. (altho in reality you wouldn't flush 
the whole JIT cache because that'd be expensive.)




More information about the Python-ideas mailing list