Python Front-end to GCC

[Steven D'Aprano]

On Sun, 20 Oct 2013 20:35:03 -0700, Mark Janssen wrote:

[Attribution to the original post has been lost]
>> Is a jit implementation of a language (not just python) better than
>> traditional ahead of time compilation.
> 
> Not at all.  The value of jit compilation, I believe, is purely for the
> dynamic functionality that it allows.  AOT compilation will never allow
> that, but in return you get massive performance and runtime-size gains

On the contrary, you have that backwards. An optimizing JIT compiler can 
often produce much more efficient, heavily optimized code than a static 
AOT compiler, and at the very least they can optimize different things 
than a static compiler can. This is why very few people think that, in 
the long run, Nuitka can be as fast as PyPy, and why PyPy's ultimate aim 
to be "faster than C" is not moonbeams:

http://morepypy.blogspot.com.au/2011/02/pypy-faster-than-c-on-carefully-crafted.html

http://morepypy.blogspot.com.au/2011/08/pypy-is-faster-than-c-again-string.html


See here for a discussion on what JIT compilers can do which static 
compilers can't:

http://en.wikipedia.org/wiki/Just-in-time_compilation


Of course, the disadvantage of a JIT compiler is that there's a certain 
amount of runtime overhead: it takes time to analyse the running code, 
and more time to compile it on the fly. This is why, for example, PyPy 
likely won't be as fast for really short-running scripts as a static 
compiler could be. Again, see the Wikipedia article.

JIT compilation is really about optimization, which is why languages like 
Java and .NET which could easily be compiled to machine code at compile 
time generally use an intermediate bytecode and a JIT compiler instead. 
They're not doing it for dynamism since they aren't dynamic languages. 
It's a way of generating more aggressive (i.e. better but harder) 
optimizations based on information only available at runtime.



-- 
Steven