The first stable release of PyPy3

http://morepypy.blogspot.com/2014/06/pypy3-231-fulcrum.html

by pjenvey • 12 years ago

299 84 12 years ago

morepypy.blogspot.com

husio• 12 years ago

Thank you.

thomasahle• 12 years ago

I wish the community would just switch entirely to pypy. Being able to just slightly performance sensitive code in python is a huge win.

masklinn• 12 years ago

I wish the community would just switch entirely to pypy.

What purpose would that serve?

Being able to just slightly performance sensitive code in python is a huge win.

I think you slightly this phrase, but aside from that pypy does not work for everybody and everything (e.g. at best it's no slower for sphinx, it really doesn't like the way docutils works). It's not like pypy's a magic wand.

quacker• 12 years ago

What purpose would that serve?

If PyPy became the official/canonical implementation, PyPy would receive more attention and third-party library compatibility would be a requirement. Complaints about Python's slowness would be somewhat less relevant, and Python might see wider adoption. The RPython toolchain would receive more attention and that could be useful to other languages. There are plenty of reasons, but PyPy is usually a free speedup for your Python application. Who's going to complain about that?

pypy does not work for everybody and everything

True, but as the official implementation of Python, compatibility with PyPy would then be a must, and this situation would be greatly improved.

ngoldbaum• 12 years ago

It makes sense to use pypy if you're writing pure python code. The second you need a C extension, you're pretty much out of luck. This kills a lot of the appeal for people in the scientific/analytics side of things, who make heavy use of legacy C and Fortran routines.

rguillebert9• 12 years ago

You can use these C and Fortran routines on PyPy, just not with the CPython C extension API.

dragonwriter2• 12 years ago

The second you need a C extension, you're pretty much out of luck.

In theory, shouldn't CFFI be the foundation of the solution to that problem?

sitkack7• 12 years ago

No, you are wrong. It supports both ctypes and cffi, both of which should be the goto for calling native code. Use PyObject has been the stupid choice for over 4 years.

jamespo• 12 years ago

Maybe moving libraries & code to Python 3 should be the priority.

cookiecaper3• 12 years ago

Convincing distros to package it as the default "python" should be the priority. Until that happens, Python 3 will see limited adoption. The path of least resistance will always have the most traffic.

ris2• 12 years ago

How much memory do you have?

dagw• 12 years ago

For a sufficient performance increase? As much as it takes. Memory is cheap

Buetol• 12 years ago

Wow, this is a very exciting moment for the Python world.

And they didn't even reached their funding goal for "py3k in pypy" [1]. This is dedication. I encourage everyone to fund this extremely incredible project!

[1] http://pypy.org/py3donate.html

chrismonsanto• 12 years ago

I have been checking the py3k branch on Hg every other day waiting for this moment, what a pleasant surprise. Very, very exciting. Thanks all.

I donated a while back, will make another donation soon.

I would like to start using this immediately but I think I'll have to wait until a 3.3 release for "yield from".

wldcordeiro• 12 years ago

This is awesome, now just to wait for a Python 3.4 PyPy release :D

Derbasti2• 12 years ago

And Numpy! And ctypes (for Matplotlib)!

Although I must say, numpypy is quite usable already!

sitkack7• 12 years ago

PyPy has had ctypes support for a great long while.

chris_mahan• 12 years ago

Excellent. I've been waiting for this for a long time.

derengel• 12 years ago

I don't know or use Python but why an implementation that is trying to be "superior" still has the GIL?

huxley• 12 years ago

This donation page has some background on how PyPy is proposing to replace the GIL with software transactional memory:

http://pypy.org/tmdonate2.html#introduction

meowface2• 12 years ago

Because it's very tricky to remove.

Ruby also has a GIL.

dragonwriter2• 12 years ago

Ruby also has a GIL.

MRI has a GIL; major alternative implementations (JRuby, Rubinius) do not.

OTOH, addressing the downsides of a GIL are not the only reasonable motivations for an alternative implementation, so there's no reason that a better-than-stock Python (or Ruby) fundamentally must remove the GIL (the current "MRI" used to be an alternative, YARV, to the old MRI, and both had GILs.)

pekk3• 12 years ago

What DO you know or use? Did you think that the GIL was an obvious and stupid oversight made by stupid people for no good reason?

glibgil4• 12 years ago

Obviously the GIL was shortsighted, yes. Leave the people out of it. The idea was stupid. There was a reason, but it wasn't a good reason.

tedunangst2• 12 years ago

Minor note: the openbsd support (at least for 2.x) is amd64 only. Building for i386 at some point requires running a bootstrap process that doesn't fit in memory.

hcarvalhoalves• 12 years ago

Building for i386 at some point requires running a bootstrap process that doesn't fit in memory.

Seriously, it takes more than 4gigs to build PyPy? Is that also necessary for other platforms besides OpenBSD?

tedunangst2• 12 years ago

I think it's 2 and some change, but yeah. I don't know the specifics. Once bootstrapped, it's more reasonable, but building from source is pretty wicked.

thristian• 12 years ago

When you're compiling CPython, it's neatly broken into little bite-sized chunks (.c files), each of which has all the type-annotations and such that the compiler needs to produce efficient code.

When you're compiling PyPy, it basically has to load the entire Python interpreter structure into memory so it can do its various analyses and annotations, so compiling PyPy takes a long time. I think for a while it was excluded from certain Linux distros because their package-build-farm machines wouldn't handle it.

sitkack7• 12 years ago

4GB is literally nothing. My laptop has 16, most servers I use have 128+. 4GB is netbook territory.

keeperofdakeys2• 12 years ago

http://stackoverflow.com/questions/8452396/does-pypy-transla...

Pypy is written in RPython, a subset of the python language. When it's 'compiled', the pypy RPython code runs in cpython or pypy, to re-compile the pypy source into C code, to generate a binary. Lots of tuning and such occurs at the same time, so the JIT runs well on the target machine. This is why it takes a long while, and lots of memory.

The build also prints a fractal while compiling. http://pypy.readthedocs.org/en/latest/faq.html#why-does-pypy...

zyngaro• 12 years ago

I've just made a small donation.

johnrds• 12 years ago

I created a simple Terminal instance that compares Python and PyPy in a performance test:

https://terminal.com/tiny/shkhWWkcEV

(this lets you compare the performance on a real Linux system, without installing anything)

codiator• 12 years ago

PyPy seems to be 7x faster!

hyperbovine• 12 years ago

On a silly piece of code that nobody would ever have any use for. I have tried PyPy for "real" data and numerical tasks from time to time, and never have I noticed any sort of speedup. Usually it's slower than CPython. Perhaps this latest version will be different, who knows.

mineo• 12 years ago

The PyPy people themselves have a benchmark portal at http://speed.pypy.org/ with graphs and everything.

voidlogic• 12 years ago

How does the performance of PyPy and Jython compare?

rguillebert9• 12 years ago

Jython is usually slower than CPython I believe, it has no GIL though.

rdtsc• 12 years ago

Wonder if it can be faster under higher parallelism conditions. Multiple threads doing some CPU intensive work?

pipeep• 12 years ago

According to Jython's (a little dated) FAQ <https://wiki.python.org/jython/JythonFaq/GeneralInfo>, "Jython is approximately as fast as CPython--sometimes faster, sometimes slower. Because most JVMs--certainly the fastest ones--do long running, hot code will run faster over time."

PyPy aims to be (and is in many cases) faster than CPython.

The advantage with Jython isn't a performance one: it's the ability to call Java code directly.

rectangletangle2• 12 years ago

Awesome, I hadn't realized this project was quite this far along. If they get PyPy 3.4/3.5 going with NumPy, it will make a really nice package. Fast Python code for the high-level logic, paired with fast low-level number crunching. This could also help speed up the adoption of Python 3.

rch• 12 years ago

Looks like they're over 80% of the way to hitting the funding goal for that one too:

http://pypy.org/numpydonate.html

ma2rten• 12 years ago

The problem is: even if numpy gets ported we still don't have scipy and a million other packages which require C bindings.

The first stable release of PyPy3

Related Stories