Python Front-end to GCC

[Ned Batchelder]

On 10/21/13 4:14 PM, Mark Janssen wrote:
> 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.

Surely we can discuss this without resorting to swearing.
>> 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.
I think Steven has earned the benefit of the doubt when it comes to 
understanding computer.  Did you read the links he provided? Do you 
believe that author also doesn't understand how computers work?

Mark, disagreement doesn't have to lead to ad-hominem attacks.  If you 
think Steven is wrong about what JIT compilers can do, please explain.  
Simply calling his statements horseshit and saying he doesn't understand 
computers is not a rebuttal.

> 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.

Please tell us what JIT compilation is about.
>
>> 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.
>
Again, a statement with no supporting information.

*sigh*

If someone says something that seems wrong to you, there are a number of 
possibilities: 1) you are wrong, 2) they are wrong, or 3) you haven't 
understood each other yet.  Please have the humility to at least 
consider option 3 first.

--Ned.