6 ms·
The first stable release of PyPy3
- wldcordeiro 12y agoThis is awesome, now just to wait for a Python 3.4 PyPy release :D
- Derbasti 12y agoAnd Numpy! And ctypes (for Matplotlib)! Although I must say, numpypy is quite usable already!
- sitkack 12y agoPyPy has had ctypes support for a great long while.
- Derbasti 12y agoTrue. Not complete enoughbfor Matplotlib, though.
- rguillebert 12y agoI think you're talking about the c extension api.
- deleted 12y ago[deleted]
- husio 12y agoThank you.
- thomasahle 12y agoI wish the community would just switch entirely to pypy. Being able to just slightly performance sensitive code in python is a huge win.
- masklinn 12y 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.
- deleted 12y ago[deleted]
- quacker 12y 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.
- BuckRogers 12y agoI agree with you, but it will never happen. GvR wants a as-simple-as-possible reference implementation, for one, he has to maintain it with a volunteer dev team. Also, there's a split in the Python community between guys like me and you- and the scientific squad. Until the scientific stuff works 100% in PyPy you'd lose a significant portion of the Python userbase by dumping CPython. GvR has done enough damage to Python with Python3. I don't intend to encourage him to do make any more changes. Us Python web developers are better off using what we have (non reference implementations, which don't hurt anyone), or just use Node.js.
- michh 12y ago
- Buetol 12y agoWow, 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 http://pypy.org/py3donate.html
- chrismonsanto 12y agoI 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".
- chris_mahan 12y agoExcellent. I've been waiting for this for a long time.
- derengel 12y agoI don't know or use Python but why an implementation that is trying to be "superior" still has the GIL?
- huxley 12y agoThis donation page has some background on how PyPy is proposing to replace the GIL with software transactional memory: http://pypy.org/tmdonate2.html#introduction http://pypy.org/tmdonate2.html#introduction
- meowface 12y agoBecause it's very tricky to remove. Ruby also has a GIL.
- dragonwriter 12y 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.)
- 12y ago
- tedunangst 12y agoMinor 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 12y 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?
- tedunangst 12y agoI 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 12y agoWhen 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.
- sitkack 12y ago4GB is literally nothing. My laptop has 16, most servers I use have 128+. 4GB is netbook territory.
- tekacs 12y ago... I think the implication is that more than 4GB would exceed the pre-[PAE][1] memory limit[2]. A form of cross-compilation might work, though PyPy build isn't exactly a simple, 'classical' build process. :P Edit: also, looking at your comments[3E] it looks like surely you know this (sorry) so I'm now really not sure what you're getting at... :P [1]: http://en.wikipedia.org/wiki/Physical_Address_Extension http://en.wikipedia.org/wiki/Physical_Address_Extension [2]: and even with PAE you still need to split into multiple processes/address spaces to do anything useful [3E]: https://news.ycombinator.com/threads?id=sitkack https://news.ycombinator.com/threads?id=sitkack
- zyngaro 12y agoI've just made a small donation.
- johnrds 12y agoI created a simple Terminal instance that compares Python and PyPy in a performance test: https://terminal.com/tiny/shkhWWkcEV https://terminal.com/tiny/shkhWWkcEV (this lets you compare the performance on a real Linux system, without installing anything)
- codiator 12y agoPyPy seems to be 7x faster!
- hyperbovine 12y agoOn 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.
- pekk 12y agoYou 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!
- rguillebert 12y agoHelp us make your code faster, report it please :)
- apendleton 12y agoI'm using it in production, and speedups tend to be on the order of 4-5x for my app (the compute-intensive part involves hierarchical agglomerative clustering of documents by text similarity, so it's data/numbers-heavy). Obviously it'll depend on your individual application (and non-CPU-bound tasks won't benefit much), but we switched to PyPy because it showed major improvements in profiling of our app on production data (and we switched around PyPy's 1.9 release, so it's even better now). It's not like everyone's just imagining the speed improvements...
- voidlogic 12y agoHow does the performance of PyPy and Jython compare?
- rguillebert 12y agoJython is usually slower than CPython I believe, it has no GIL though.
- pipeep 12y agoAccording to Jython's (a little dated) FAQ <https://wiki.python.org/jython/JythonFaq/GeneralInfo> 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.
- rectangletangle 12y agoAwesome, 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 12y agoLooks like they're over 80% of the way to hitting the funding goal for that one too: http://pypy.org/numpydonate.html http://pypy.org/numpydonate.html
- ma2rten 12y agoThe problem is: even if numpy gets ported we still don't have scipy and a million other packages which require C bindings.
- rectangletangle 12y agoTrue. Though this will likely make PyPy more mainstream, and thus it'll hopefully attain more community support.
- RaecKK 12y agoAfter searching far and wide for a solution to improve Python performance, I stumbled upon the post "The sweet trap of dynamic languages and development time"ꝉ. I think the case for Python begins to deteriorate as the project grows in complexity, and performance begins to matter greatly. PyPy is competing in this regard with Julia and Nimrod. "Languages like C++ are not the solution, and dynamic languages end up disappointing when you grow past single programmer code. Isn't there a middle ground? There is: instead of patching an old decrepit corpse, start from zero using what you have learned. Start using the Nimrod programming language, which would look like this for the previous examples:" import uri, strutils proc shortestURL(urls: seq[TUrl]): TUrl = if urls.len < 1: return TUrl(nil) if urls.len < 2: return urls[0] var url = urls[0] length = len($url) for i in 1 .. <urls.len: let test = urls[i] if len($test) < length: url = test length = len($test) return url proc testShortestURL() = echo "shorty is ", shortestURL(@[ TUrl("http://www.google.es"), TUrl("http://google.es")]) Nimrod compiles this code to pure ANSI C. It isn't dependent on a virtual machine, and produces small executables without dependencies, reminiscent of Go. ꝉ https://gradha.github.io/articles/2014/03/the-sweet-trap-of-dynamic-languages-and-development-time.html https://gradha.github.io/articles/2014/03/the-sweet-trap-of-...