On Tue, 10 Nov 2015 11:14 pm, Ben Finney wrote: >> Python -- yes, even CPython -- has a runtime compiler. When you import >> a module, it is compiled (if needed) just before the import. Likewise, >> when you call the `compile`, `eval` or `exec` built-ins, the compiler >> operates. >> >> I'm not calling this a JIT compiler, because the simple-minded >> compilation performed by `compile` etc doesn't use any run-time >> information. It just statically compiles the code to byte-code. > > That's what I though. I'm aware of JIT compilers, and was pretty sure > Python doesn't have them.
What do you think PyPy is then? CPython is intentionally a pretty simple-minded compiler. Even no-brainer constant folding is mildly controversial among some Python devs. But CPython isn't "Python", it is just the reference implementation. Nuitka aims to be an optimized AOT (Ahead Of Time) Python compiler, and PyPy is already a state of the art (if not cutting edge) JIT Python compiler. And if Victor Skinner's experimental FAT Python works out, even CPython itself will gain some simple JIT techniques, rather similar to what Psycho was doing ten years ago. > What's more, if it operates at a whole-module > level, and not later than when the module is imported. Now you're getting into implementation details of the JIT compiler. Can it track entities across modules? How exactly does it operate? PyPy is a "tracing JIT", which (if I have understood correctly) means it actually analyses the code as it runs, using knowledge gained at runtime to dynamically decide what to compile. This means that PyPy is best suited to code that has long-running loops, and not well suited to scripts that don't run for a long time. But another (hypothetical) JIT compiler might be more like Psycho. > Under those conditions, I maintain my objection to the proposed > optimisation. > > The proposal is explicitly for optimisations made by the Python > compiler. As proposed, it only seems to be worthwhile once Python no > longer has a distinct “compiler” and “interpreter” is dissolved. Until > then, it seems pointless. Python has not had a distinct "compiler" and "interpreter" since about version 0.1. The execution module of Python as a dynamic byte-code compiled, interpreted language with eval and exec *depends* on the compiler being available during the execution phase, i.e. at runtime. Some of the things I've suggested already exist, and have proven that they work: Psycho and PyPy, to say nothing of similar technologies for other equally dynamic languages such as Javascript and Smalltalk. Others are state of the art compiler techniques -- they might not have been applied to *Python* but that's only because nobody has got around to it, not because it can't be done. I daresay that there are implementation challenges to making Python faster than it is without compromising on the semantics of the language, but there is nothing fundamentally impossible about the idea. Ben, I know that the IT crowd is rather conservative, and the Python community even more so, but at the point where you are denying the possibility of technologies which *already exist* I think that things have got a bit out of hand. It's a bit like somebody getting on Twitter to tweet "A globally interconnected communication network allowing computers all over the world to communicate? Impossible! And even if it were possible, nobody would use it." ;-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
