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 -- https://mail.python.org/mailman/listinfo/python-list
