Python Front-end to GCC

[Steven D'Aprano]

On Mon, 21 Oct 2013 10:55:10 +0100, Oscar Benjamin wrote:

> On 21 October 2013 08:46, Steven D'Aprano <steve at pearwood.info> wrote:

>> 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:
> 
> That may be true but both the examples below are spurious at best. A
> decent AOT compiler would reduce both programs to the NULL program as
> noted by haypo:
> http://morepypy.blogspot.co.uk/2011/02/pypy-faster-than-c-on-carefully-
crafted.html?showComment=1297205903746#c2530451800553246683

Are you suggesting that gcc is not a decent compiler? If "optimize away 
to the null program" is such an obvious thing to do, why doesn't the most 
popular C compiler in the [FOSS] world do it?


[...]
> So the pypy version takes twice as long to run this. That's impressive
> but it's not "faster than C".

Nobody is saying that PyPy is *generally* capable of making any arbitrary 
piece of code run as fast as hand-written C code. You'll notice that the 
PyPy posts are described as *carefully crafted* examples.

I believe that, realistically, PyPy has potential to bring Python into 
Java and .Net territories, namely to run typical benchmarks within an 
order of magnitude of C speeds on the same benchmarks. C is a very hard 
target to beat, because vanilla C code does *so little* compared to other 
languages: no garbage collection, no runtime dynamism, very little 
polymorphism. So benchmarking simple algorithms plays to C's strengths, 
while ignoring C's weaknesses.



-- 
Steven