Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <5264dbbe$0$30000$c3e8da3$5496439d@news.astraweb.com>
References: <4012031f-5334-4be8-a673-e0d8c8917fb2@googlegroups.com> <mailman.1295.1382326510.18130.python-list@python.org> <5264dbbe$0$30000$c3e8da3$5496439d@news.astraweb.com>
From: Oscar Benjamin <oscar.j.benjamin@gmail.com>
Date: Mon, 21 Oct 2013 10:55:10 +0100
Subject: Re: Python Front-end to GCC
To: "Steven D'Aprano" <steve@pearwood.info>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Python List <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1308.1382349341.18130.python-list@python.org>
Lines: 91
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:57190

On 21 October 2013 08:46, Steven D'Aprano <steve@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, 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

> http://morepypy.blogspot.com.au/2011/02/pypy-faster-than-c-on-carefully-crafted.html
>
> http://morepypy.blogspot.com.au/2011/08/pypy-is-faster-than-c-again-string.html

I just modified the add() example so that none of the operations can
be entirely optimised away:

def main():
    i = 0
    a = 0.0
    b = 0.0
    while i < 1000000000:
        a += 1.0
        b += add(a, a)
        i += 1
    print(b)

Similarly for the C version:

#include <stdio.h>

double add(double a, double b);

int main()
{
  int i = 0;
  double a = 0;
  double b = 0;
  while (i < 1000000000) {
    a += 1.0;
    b += add(a, a);
    i++;
  }
  printf("%f", b);
}

My timings:

$ gcc -O3 x.c y.c
$ time ./a.exe
1000000000134218000.000000
real    0m5.609s
user    0m0.015s
sys     0m0.000s
$ time pypy y.py
1.00000000013e+18

real    0m9.891s
user    0m0.060s
sys     0m0.061s

So the pypy version takes twice as long to run this. That's impressive
but it's not "faster than C".

I also compared a script that uses intensive decimal computation run
under CPython 3.3 and PyPy 2.1 (pyver 2.7). This is essentially a
comparison between the C implementation of the decimal module and
pypy's jit'd optimisation of the pure Python module. CPython 3.3 takes
10 seconds and PyPy 2.1 takes 45 seconds. Again that's impressive (a
lot of work went into making the C implementation of the decimal
module as fast as it is) but it's not faster than C.

I don't mean to criticise PyPy. I've just tested it and I am impressed
and I think I'll definitely try and use it where possible. I do think
that some of the marketing there is misleading though.


Oscar