3 ms·

> but (afaik) python is not very jit-friendly in general. It's time for the time honored "Sufficiently Smart Compiler" [0] argument. All programming languages

> but (afaik) python is not very jit-friendly in general. It's time for the time honored "Sufficiently Smart Compiler" [0] argument. All programming languages can be optimized in meaningful ways via inferred information. There is a small subset of python programs that I don't see as possible to optimize at all. These programs would be ones using the Pickle library who load code and execute functions from that code. So long as your code is not doing any Evil/Eval() all performance critical portions of your code should theoretically be inferrable. Note: I said "should be inferrable" NOT "should be easily inferrable". This won't be easy and it takes teams of people to do this on a subset of python's feature set (see Numba). [0] - http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler

valarauca1 9y ago
I’m just gonna jump in. The JVM has no problem hot loading, unloading, or redefining presently executed code. What I’m trying to say is JIT’ing dynamically loaded code isn’t rocket science
- gravypod 9y ago
  It's much more complicated and a much lower on the cost-benefit totem-pole than... 1. Inlining 2. Compiling bytecode for a specific set of input and output types 3. Object Recycling 4. Runtime-compiling to machine code Things like that. edit: I may be wrong. I'd love to see an example of a VM that implements what you're thinking.
  - dr_zoidberg 9y ago
    While the name of the talk implies it's a generally-speaking-talk, Click goes into a lot of detail of how the JVM works in his "A Crash Course in Modern Hardware" presentation[0]. I saw it a while ago, but I think he does mention those things. Of course that's the one I saw and remember, but you could probably find another presentation in which he goes into much better detail about the JVM and its inner workings. [0] https://www.youtube.com/watch?v=OFgxAFdxYAQ https://www.youtube.com/watch?v=OFgxAFdxYAQ
wruza 9y ago
To my shallow understanding of tracing compilers, eval is not a problem at all since they compile repeating traces (superblocks), not particular function sets nor modules. What you can run you can compile. Iirc, python has too many logic inside vm, so compiling opcodes makes the result no less than ‘efficiently’ calling python internal API, which cannot be optimized since it is written out of vm; compiler has no clue what it does and how to apply transformations on it. To my understanding again, from what I read on topic, if you write a dead simple vm and all higher logic goes to language libraries, i.e. is expressed in the same opcode set, then the runtime will be more explainable to the jit (since all magic will be in trace, explicitly) and optimizations may reduce such stdlibs to series of native instructions not calling any API at all. This is the case with Lua, where the language has very small and strict opcode set, and probably javascript, which is slightly heavier, but still doesn’t involve too much magic. It is also dummier to my opinion (constant lexical scoping, no green threads, no function environments), so there is a balance between magic, simplicity and money thrown at.

valarauca1 9y ago

I’m just gonna jump in. The JVM has no problem hot loading, unloading, or redefining presently executed code. What I’m trying to say is JIT’ing dynamically loaded code isn’t rocket science

gravypod 9y ago
It's much more complicated and a much lower on the cost-benefit totem-pole than... 1. Inlining 2. Compiling bytecode for a specific set of input and output types 3. Object Recycling 4. Runtime-compiling to machine code Things like that. edit: I may be wrong. I'd love to see an example of a VM that implements what you're thinking.
- dr_zoidberg 9y ago
  While the name of the talk implies it's a generally-speaking-talk, Click goes into a lot of detail of how the JVM works in his "A Crash Course in Modern Hardware" presentation[0]. I saw it a while ago, but I think he does mention those things. Of course that's the one I saw and remember, but you could probably find another presentation in which he goes into much better detail about the JVM and its inner workings. [0] https://www.youtube.com/watch?v=OFgxAFdxYAQ https://www.youtube.com/watch?v=OFgxAFdxYAQ

wruza 9y ago

To my shallow understanding of tracing compilers, eval is not a problem at all since they compile repeating traces (superblocks), not particular function sets nor modules. What you can run you can compile. Iirc, python has too many logic inside vm, so compiling opcodes makes the result no less than ‘efficiently’ calling python internal API, which cannot be optimized since it is written out of vm; compiler has no clue what it does and how to apply transformations on it. To my understanding again, from what I read on topic, if you write a dead simple vm and all higher logic goes to language libraries, i.e. is expressed in the same opcode set, then the runtime will be more explainable to the jit (since all magic will be in trace, explicitly) and optimizations may reduce such stdlibs to series of native instructions not calling any API at all. This is the case with Lua, where the language has very small and strict opcode set, and probably javascript, which is slightly heavier, but still doesn’t involve too much magic. It is also dummier to my opinion (constant lexical scoping, no green threads, no function environments), so there is a balance between magic, simplicity and money thrown at.