On Mon, 21 Oct 2013 10:55:10 +0100, Oscar Benjamin wrote: > On 21 October 2013 08:46, Steven D'Aprano <st...@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 -- https://mail.python.org/mailman/listinfo/python-list
