Python Front-end to GCC

[Mark Janssen]

On Mon, Oct 21, 2013 at 12:46 AM, Steven D'Aprano <steve at 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