The first stable release of PyPy3 • Hacker News Board

Re: The first stable release of PyPy3

#31

Post by quacker » Sat, Jun 21, 2014, 12:28 AM UTC

masklinn wrote: post #6

thomasahle wrote: post #3

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

> 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.

> 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.

Re: The first stable release of PyPy3

#32

Post by rguillebert » Sat, Jun 21, 2014, 12:31 AM UTC

takluyver wrote: post #27

rguillebert wrote: post #16

Earlier quoted context omitted.

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

There's a lot of established code built around the C API. It's not like it can just be rewritten using CFFI over a weekend.

Well, I'm not talking about every C extension in the world, I'm talking about thin bindings around C routines which is what numpy has for fft for example, someone wrote a basic equivalent for numpypy in a few hours with no prior numpypy/cffi knowledge.

Re: The first stable release of PyPy3

#33

Post by tedunangst » Sat, Jun 21, 2014, 12:33 AM UTC

hcarvalhoalves wrote: post #18

tedunangst wrote: post #13

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.

> 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?

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.

Re: The first stable release of PyPy3

#34

Post by hyperbovine » Sat, Jun 21, 2014, 12:55 AM UTC

codiator wrote: post #29

johnrds wrote: post #28

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)

PyPy seems to be 7x faster!

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.

Re: The first stable release of PyPy3

#35

Post by voidlogic » Sat, Jun 21, 2014, 12:56 AM UTC

How does the performance of PyPy and Jython compare?

Re: The first stable release of PyPy3

#36

Post by meowface » Sat, Jun 21, 2014, 1:06 AM UTC

dragonwriter wrote: post #22

meowface wrote: post #17

Earlier quoted context omitted.

Because it's very tricky to remove. Ruby also has a GIL.

> 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.)

True. Jython and IronPython also do not have a GIL.

Re: The first stable release of PyPy3

#37

Post by pekk » Sat, Jun 21, 2014, 1:07 AM UTC

hyperbovine wrote: post #34

codiator wrote: post #29

Earlier quoted context omitted.

PyPy seems to be 7x faster!

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.

You might try again since things have changed. If you don't get any kind of speedup, the PyPy project would likely consider it a bug and it would be helpful to document that it was slower. Please consider finding some way of reporting the specific measurable issues you find!

Re: The first stable release of PyPy3

#38

Post by glibgil » Sat, Jun 21, 2014, 1:10 AM UTC

pekk wrote: post #19

derengel wrote: post #9

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

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?

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.

Re: The first stable release of PyPy3

#39

Post by rguillebert » Sat, Jun 21, 2014, 1:11 AM UTC

hyperbovine wrote: post #34

codiator wrote: post #29

Earlier quoted context omitted.

PyPy seems to be 7x faster!

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.

Help us make your code faster, report it please :)

Re: The first stable release of PyPy3

#40

Post by rectangletangle » Sat, Jun 21, 2014, 1:50 AM UTC

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.