How does the performance of PyPy and Jython compare?
Jython is usually slower than CPython I believe, it has no GIL though.
The first stable release of PyPy3
41–50 of 92 posts
Re: The first stable release of PyPy3
#42How does the performance of PyPy and Jython compare?
According to Jython's (a little dated) FAQ " rel="nofollow">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.
Re: The first stable release of PyPy3
#43Earlier quoted context omitted.
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.
What would you replace it with ?
Re: The first stable release of PyPy3
#44Minor 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?
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.
Re: The first stable release of PyPy3
#45Earlier quoted context omitted.
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.
Unfortunately, NumPy uses deep knowledge of the CPython API in quite a few places, which is one of the reasons implementing NumPyPy has been so challenging.
Re: The first stable release of PyPy3
#46Re: The first stable release of PyPy3
#47Minor 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?
4GB is literally nothing. My laptop has 16, most servers I use have 128+. 4GB is netbook territory.
Re: The first stable release of PyPy3
#48I wish the community would just switch entirely to pypy. Being able to just slightly performance sensitive code in python is a huge win.
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.
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.
Re: The first stable release of PyPy3
#49Earlier quoted context omitted.
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.
Unfortunately, NumPy uses deep knowledge of the CPython API in quite a few places, which is one of the reasons implementing NumPyPy has been so challenging.
Another approach should be used for those, but to be clear I wasn't talking about the entire numpy library, I'm talking about things like numpy.fft
Re: The first stable release of PyPy3
#50Earlier quoted context omitted.
Jython is usually slower than CPython I believe, it has no GIL though.
Wonder if it can be faster under higher parallelism conditions. Multiple threads doing some CPU intensive work?
Jython can utilize threads as well as Java can, so on many core machine Jython wins by a pretty large margin.