PyPy 1.0: JIT compilers for free and more

[Carl Friedrich Bolz]

> Nice to read that things are going on. I've still a PyPy 0.7 version
> on my notebook. I guess I will upgrade
>
> A somewhat unrelated question. With Py3K Python gets optional type
> annotations. Are you already architecting an annotation handler that
> can process these annotations? This feature is somewhat competitive to
> all the complicated type inference and jitting you have been worked
> out so I don't know how it fits well into the current PyPy
> architecture?

I don't see at all why type annotations are competitive to the type
inference that PyPy's translation toolchain is doing. The type inference
of PyPy is an artefact of the way we are implementing our interpreter
(namely in RPython). You also wouldn't say that the static typing of C
is competitive to type annotations because CPython is written in C,
right?

The JIT (which is completely independent from our type inference engine)
will hopefully deal well with the eventual addition of type annotations
(it's not clear to me how soon we will start supporting Py3k features,
we are not even fully supporting Python 2.5 yet). Since the JIT is
automatically generated out of the Python interpreter it should deal
with any sort of language changes rather well. Whether that is true in
practice remains to be seen, but this is one of the reason why PyPy was
started in the first place.

Also, I fail to see how type annotations can have a huge speed-advantage
versus what our JIT and Psyco are doing. Imagine you have a function
that is nicely algorithmic, takes only integers as arguments and only
does some calculations with them. If you have a Psyco-like scheme, the
JIT will note that you are using it mostly with ints, generate
relatively efficient assembly for the whole function (at least after it
has been called several times). If you call that functions, the
arguments are checked whether they are integers and then the fast
assembly code is used without any further type checks. How can you
improve on this with type annotations? If the type annotations say that
your arguments have to be ints, you _still_ have to check whether this
is true. So it is not faster than what Psyco is doing and has the
disadvantage that it only works with ints -- good bye, duck typing.
Psyco on the other hand will be perfectly happy with you using a custom
class that looks mostly like an int and generate assembly optimized for
this situation.

Cheers,

Carl Friedrich Bolz

 

[Carl Friedrich Bolz]

> Nice to read that things are going on. I've still a PyPy 0.7 version
> on my notebook. I guess I will upgrade
>
> A somewhat unrelated question. With Py3K Python gets optional type
> annotations. Are you already architecting an annotation handler that
> can process these annotations? This feature is somewhat competitive to
> all the complicated type inference and jitting you have been worked
> out so I don't know how it fits well into the current PyPy
> architecture?

I don't see at all why type annotations are competitive to the type
inference that PyPy's translation toolchain is doing. The type inference
of PyPy is an artefact of the way we are implementing our interpreter
(namely in RPython). You also wouldn't say that the static typing of C
is competitive to type annotations because CPython is written in C,
right?

The JIT (which is completely independent from our type inference engine)
will hopefully deal well with the eventual addition of type annotations
(it's not clear to me how soon we will start supporting Py3k features,
we are not even fully supporting Python 2.5 yet). Since the JIT is
automatically generated out of the Python interpreter it should deal
with any sort of language changes rather well. Whether that is true in
practice remains to be seen, but this is one of the reason why PyPy was
started in the first place.

Also, I fail to see how type annotations can have a huge speed-advantage
versus what our JIT and Psyco are doing. Imagine you have a function
that is nicely algorithmic, takes only integers as arguments and only
does some calculations with them. If you have a Psyco-like scheme, the
JIT will note that you are using it mostly with ints, generate
relatively efficient assembly for the whole function (at least after it
has been called several times). If you call that functions, the
arguments are checked whether they are integers and then the fast
assembly code is used without any further type checks. How can you
improve on this with type annotations? If the type annotations say that
your arguments have to be ints, you _still_ have to check whether this
is true. So it is not faster than what Psyco is doing and has the
disadvantage that it only works with ints -- good bye, duck typing.
Psyco on the other hand will be perfectly happy with you using a custom
class that looks mostly like an int and generate assembly optimized for
this situation.

Cheers,

Carl Friedrich Bolz

 

[Christian Tismer]

Carl Friedrich Bolz napisał(a):


So it took 4 yars of work and over 2 yaers of consumption of EU funds,
yeah, great.

Could anybody explain, what this gives to Python and its users? Would
we, eventually, get GIL-free VM, that is capable to consume all
available power of multicore processors? Or, maybe, we'll get
something
special, I am unable to dream of? Or is it purely academic project to
create Python VM in Python?

It will eventually give you a GIL-free VM, and it already gives you
a lot more than you have dreamt of.

There is one feature missing that is probably hard to add.
Handling the 'posters who are not willing to read before they post'
syndrome.

cheers - chris

 

[Robin Becker]

Christian Tismer wrote:
........

It will eventually give you a GIL-free VM, and it already gives you
a lot more than you have dreamt of.

There is one feature missing that is probably hard to add.
Handling the 'posters who are not willing to read before they post'
syndrome.

........

I come from an academic background (sadly not in computer science) so I
understand the need to promote the abstract advances that are being made here.

However, I am a bit confused about the applicability of pypy. All the talk of
backends, annotation object spaces etc etc may make some sense to really
interested parties, but I would like to know what I can do in real terms with
the new interpreters?

The demo javascript stuff seems a bit fake since others have already done some
work in that direction already using ordinary python. RPython may be larger or
smaller than those subsets, but that's not clear.

I would be interested to know if it's possible to point a tool at an existing
python-2.4 module and wrap it into a much faster extension that can be used by
my CPython stuff. I know there is preliminary work in that direction.

I am hugely encouraged by this

C:\Python\devel\pypy-1.0.0>\python24\python \python\lib\test\pystone.py
Pystone(1.1) time for 50000 passes = 1.49586
This machine benchmarks at 33425.6 pystones/second

C:\Python\devel\pypy-1.0.0>.\pypy-c.exe \python\lib\test\pystone.py
Pystone(1.1) time for 50000 passes = 2.16123e-005
This machine benchmarks at 2.3135e+009 pystones/second


not

 

[Duncan Booth]

I am hugely encouraged by this

C:\Python\devel\pypy-1.0.0>\python24\python \python\lib\test \pystone.py
Pystone(1.1) time for 50000 passes = 1.49586
This machine benchmarks at 33425.6 pystones/second

C:\Python\devel\pypy-1.0.0>.\pypy-c.exe \python\lib\test\pystone.py
Pystone(1.1) time for 50000 passes = 2.16123e-005
This machine benchmarks at 2.3135e+009 pystones/second


not

It looks like time.clock() is completely borked.

C:\work\pypy-1.0.0>\python25\python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.

1.6203176660720846e-005
3.000427987355935 8.2580051375244619
11.258311321690327 16.283118664523005
19.283642753478446

C:\work\pypy-1.0.0>pypy-c
Python 2.4.1 (pypy 1.0.0 build 41438) on win32
Type "help", "copyright", "credits" or "license" for more information.

1.0000000000337512
1.0000050338639583 1.0000103837992871
1.0000154196831568

Or perhaps it is simply telling you the sort of speeds it hopes to reach
some day (I wouldn't say no to 9.16021e+009 pystones/second if that was
what it actually did).

 

[Bart Ogryczak]

Carl Friedrich Bolz napisa³(a):


So it took 4 yars of work and over 2 yaers of consumption of EU funds,
yeah, great.

Could anybody explain, what this gives to Python and its users? Would
we, eventually, get GIL-free VM, that is capable to consume all
available power of multicore processors?
http://codespeak.net/pypy/dist/pypy/doc/stackless.html

Or, maybe, we'll get something
special, I am unable to dream of? Or is it purely academic project to
create Python VM in Python?

RTFM.

 

[Carl Friedrich Bolz]

It looks like time.clock() is completely borked.

time.clock was indeed borked under windows (of by a factor of 1000).
fixed in svn now.

Cheers,

Carl Friedrich

 

[Carl Friedrich Bolz]

It looks like time.clock() is completely borked.

time.clock was indeed borked under windows (of by a factor of 1000).
fixed in svn now.

Cheers,

Carl Friedrich

 

[sjdevnull]

Carl Friedrich Bolz napisa³(a):


So it took 4 yars of work and over 2 yaers of consumption of EU funds,
yeah, great.

Could anybody explain, what this gives to Python and its users? Would
we, eventually, get GIL-free VM, that is capable to consume all
available power of multicore processors?

That is the eventual hope, along with a faster Python interpreter
(with a true functional JIT), and stackless features, and more easily
developed syntax, and retargetable front- and back- ends (allowing,
e.g. easier development of Python on the .NET CLI, JVM, etc, or other
languages like Javascript, Lisp, or whatever on the PyPy VM), and fast
extensions written in RPython instead of C, and many other features.

 

[Jacob Hallen]

Carl Friedrich Bolz napisa³(a):


So it took 4 yars of work and over 2 yaers of consumption of EU funds,
yeah, great.

Could anybody explain, what this gives to Python and its users? Would
we, eventually, get GIL-free VM, that is capable to consume all
available power of multicore processors? Or, maybe, we'll get something
special, I am unable to dream of? Or is it purely academic project to
create Python VM in Python?

No, PyPy is not a purely academic project. It has been a practically oriented
project from the very start.

For the regular user of Python, the main benefit of PyPy is execution speed.
With the Just-in-time optimizer, we have examples of functions doing
integer math that are 63 times faster than CPython. Further work will
broaden the scope of the optimizations to other language constructs.
Bulding the framework for the JIT took a long time. Now that it is in
place, extending the range of optimizations is a much smaller task.

For the Python language developers, PyPy offers an easy environment for
testing new ideas. Changes and alternative solutions can more quickly
be implemented in Python than in C.

For people who want to broaden the scope of Python, there is the option
of using some of the models that the PyPy project has implemented,
or roll their own. Constraints satisfaction, lazy evaluation, cooperative
massive multitasking, security oriented environments, transparent
distributed computing and persistence are examples of things the project
have implemented. There are some very neat APIs so that you can easily
add your own behaviour to the Python interpreter.

For those who want to do Computer Science, PyPy offers a wonderful
research platform. For instance, you can experiment with alternate
or even multiple implementations of builtin types. You can build frontends
for your favourite programming language and backends for your favourite
platform. Since Javascript is a backend that we already handle fairly
well, you can write your FORTRAN parser and have a FORTRAN to JS compiler.
The neat thing is that once you build the parser, you should automatically
have your code working on all the different backends. (This is a goal and
not quite reality at this point in time. Bugs and shortcomings will still
be in the way.)

There is a tradeoff in computer language design between execution speed
flexibility and ease of use. I personally think that PyPy is about to
break out of the tradeoff and bring it to another level. I know that I am
biased, having been involved with the project from the start, but I
think that it is the most interesting work in CS in many years.

Jacob Hallén


--