On Mon, Oct 21, 2013 at 12:46 AM, Steven D'Aprano <st...@pearwood.info> wrote: > 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,
This is horseshit. > and at the very least they can optimize different things > than a static compiler can. Okay sure. But now you've watered down your claim that's it's not saying much of anything. > 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: It is moonbeams, but that's a good thing. I think you don't understand how computers work, Steven. In any event, PyPy is a great project for those who want experiment with compiler and language design. > JIT compilation is really about optimization, No. > 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. This must is true, but not for reasons you understand. -- MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list