3 ms·
JIT-compiling your C code covers one of the two reasons a Python programmer might write C code (dropping down to C to do some mathematical operation faster). H
by JonathonW 10y ago
JIT-compiling your C code covers one of the two reasons a Python programmer might write C code (dropping down to C to do some mathematical operation faster).
How do you handle the other reason people write C code-- to bridge Python code to an external native library? In that case, you'd be JIT-compiling the bridge itself, but your native library remains "opaque [insert language here] stuff" that the JIT can't do anything with.
- chrisseaton 10y agoEither you can interpret the external native library as well, if you have the source code, or you can leave the calls to that library as normal native calls generated by the JIT. So yes, that'll be an optimisation barrier, but it's the same barrier as you would already have if you were using an interpreter for Python making native calls to the same library. So it won't be any slower than our current best case. (In fact the JIT can do some clever things to make the native call more efficient than in general, as it can do things like schedule values to be in the correct registers from the start rather than copying them in place just for the call, but that's probably not a significant source of inefficiency anyway).
- __s 10y agoWhat of JITing x86 assembly into x86?
- johncolanduoni 10y agoThis is basically how QEMU works when it's not using KVM
- chrisseaton 10y agoYes that's another option. We already do that for inline assembly in C programs.
- weberc2 10y agoIf you're using C for interop and not performance, it doesn't matter (much) if the JIT can optimize for it or not. You'll still be no worse off than you are today with CPython + C extensions.
- deleted 10y ago[deleted]