16 ms·
PyPy 1.5 Released: Catching Up
- carlosedp 15y agoI wonder how hard is the integration of Stackless and the JIT features. That would be killer.
- kingkilr 15y agoThere's actually a sprint going on right now (where this release was done), and that was a topic of discussion. I don't think anyone has written up the conclusions yet, but estimate I heard was that it'd be about 1-month of person-work.
- carlosedp 15y agoFantastic... Christian worked hard on Stackless and I think it`s a great feature. On Pypy it would be easier to maintain and add functionality, unfortunately, I struggle on Stackless internals and it`s low level C gimmicks so I can't help on it. It would be great to have something like a good framework in the future to make it`s adoption easier. We have the Stackless Examples project to address this initial learning curve thing. http://code.google.com/p/stacklessexamples/ http://code.google.com/p/stacklessexamples/
- kingkilr 15y agoYes, unfortunately Christain couldn't make it to the sprint, we would have liked to have him there. However, Kristjian (sp?) from CCP who maintains Stackless was there.
- euccastro 15y agoKristján.
- carlosedp 15y agoNice, the CCP guys are great maintaining Stackless... Kristjan and Richard do a great job on it. If there are any clues or tips on how can I help out, it would be a pleasure.
- euccastro 15y agoHave you asked in the Stackless mailing list?
- sciurus 15y agoI'm impressed that they support the features of CPython 2.7 already. PyPy seems to be developing much faster than other alternate python implementations.
- kingkilr 15y agoIronPython actually beat us to 2.7, however I will note that it was pretty fast. We went from 2.5 to 2.7 support in under 12 months.
- kbd 15y agoI will love it if in a couple of years the mainstream implementation of Python is PyPy. People are going to be upgrading their Python installations anyway when they move to Python 3. If y'all can get Python 3 support in, maybe people will switch to PyPy at the same time. I just wish Google would throw some support your way.
- sho_hn 15y agoIndeed, what are your current plans for Python 3.x?
- kingkilr 15y agoFuture cloudy, ask again later :) Because of the way our JIT is written it would be entirely possible for us to branch for py3k and put JIT improvements on both with relatively little effort, it's likely that at least our next release will still be 2.x and just feature optimizations though.
- sho_hn 15y agoHere's one vote for focussing on py3k sooner rather than later, fwiw :). I understand you're anxious to reap some rewards and see (more) production use at this point, but as a big fan of much of what was done to the language in py3k and having made the switch already, PyPy vs. CPython 3.x is an unhappy dilemma for me :).
- va_coder 15y agoMaybe this is a dumb question but why not just work on making CPython faster? Edit: I guess this provides insights: http://codespeak.net/pypy/dist/pypy/doc/architecture.html http://codespeak.net/pypy/dist/pypy/doc/architecture.html
- kingkilr 15y agoI wish I could find the video the talk where we explained this in great detail, but basically: it's hard, it's been tried and failed (notably by Armin Rigo, one of the leads of PyPy). Adding a new GC to CPython is insanely hard, and manually writing a JIT for Python even moreso.
- riobard 15y agoUnladen Swallow seems to indicate that making CPython substantially faster in the general way is not feasible as of now.
- erez 15y agoI'm really interested in this project. The abundance of C as "the new machine language" for language implementation, as well as the JVM-based languages, makes me wonder what it means for the programming language landscape. I would be very interested in learning whether this un-C implementation made any difference to Python, and what can be learned from it in way of other language implementations
- justincormack 15y agoThe benchmark here http://attractivechaos.github.com/plb/ http://attractivechaos.github.com/plb/ suggests they are doing much better on performance than they were a while back. Its a straight numeric benchmark so not relevant for everything but its better than V8 which is good work.
- kingkilr 15y ago1.5 should be a lot better on these, the Loop Invariant Code Motion really helps on very tight loops, as these benchmarks often have.
- justincormack 15y agoThats great. Dynamic languages at say Java like speeds is a real game changer over the PHP/Rubylevel speeds. At the moment we only have LuaJIT proving its possible, but PyPy is the next contender.
- swannodette 15y agoWhile this is great news for Python, there are quite a few dynamic languages now beyond LuaJIT showing that it's possible to get stellar perf - JavaScript, Racket, Clojure.
- dman 15y agoDone leave common lisp out - sbcl is no slouch and hasnt been for quite some time.
- swannodette 15y agoTotally forgot, Common Lisp's performance w/o sacrificing dynamism is what got me excited about Lisp in the first place.
- kragen 15y ago
- ch0wn 15y agoAny chance you could update your Ubuntu PPAs soon?
- thristian 15y agoMy sentiments exactly: I would love to have a reasonably up-to-date PyPy around to try things in, but I'm not yet so invested in the project that I'm willing to watch for release announcements and download source-tarballs (or binary tarballs). Having a reliably updated PPA is pretty much exactly what I'm looking for.
- StavrosK 15y agoSince you can't see votes, pretty please yes, this.
- amix 15y agoI did a benchmark of Unladed Swallow 1.5 years ago and at this time PyPy looked like a very academic project. It could not really run any interesting code. At this time Unladed Swallow looked like a great project since improving cPython rather than starting from scratch seemed much easier, especially since Unladed Swallow based their JIT optimization on LLVM's JIT engine. I also recall reading PyPy's blog, especially a blog post about their Prolog based JIT prototype and I thought "wow, this sure seems like a complicated way to implement a JIT engine, I wonder if they will ever implement something that can run real code". Fast forward to today and Unladed Swallow is dead and PyPy has implemented a Python implementation that's compatible with Python 2.7 and beats cPython 2.6 on various benchmarks. Pretty impressive and kudos to the PyPy team.
- luismgz 15y agoMany people seem to ignore that pypy is not a new project. It's been on the works for more than 8 years now.
- illumen 15y agoIt's also had a lot of funding, and more full time workers than on CPython (who has zero full time coders).
- chubot 15y agoExactly my thoughts -- it seemed like a crazy research project, generating an interpreter written in C, and ones for jvm and clr. And it has 3 different pluggable garbage collectors apparently. But I'm impressed that it actually runs my code, in contrast to the other alternative Python implementations I've tried. Look forward to seeing more of sandboxed mode, which has been a much desired feature of CPython for many years now. And stackless mode. I just hope they can get the executable size and build times to a reasonable level.
- andrewcooke 15y agosomewhere on the net are comments i made about european idealists v american pragmatists (the whole "worse is better" thing). i have never been so glad to be proved completely wrong :o)
- wnoise 15y agoWhy did they decide on a name that can easily be (mis)pronounced as a synonym for urine? That just seems like a poor branding decision, up there with "blur-ray".
- wriq 15y agoWorked out ok for Nintendo on the Wii...
- wnoise 15y agoFair enough.
- timknauf 15y agoI've always pronounced it like "pie pie". (But then again, maybe that's because I already knew the "py" was the first syllable of the word "python"?)
- njharman 15y agoWhat language uses "ee' sound for "y"? And who pronounces blue, blur?
- Symmetry 15y agoI wouldn't say Blu-ray has much to worry about on the "blur-ray" front. Plays on words like that are damaging when they call attention to real or perceived weaknesses in a product, but while I can think of a lot of mean things to accuse Blu-ray of, blurry simply isn't one of them.
- john7 15y agoCan numpy be used with pypy? Or are there plans for that?
- kingkilr 15y agoThere are plans, but nothing yet, this reddit thread has some decent information: http://www.reddit.com/r/Python/comments/h0uuv/pypy_15_released_catching_up/ http://www.reddit.com/r/Python/comments/h0uuv/pypy_15_releas...
- hyperbovine 15y agoI'd like to second the request for a very detailed blog post written by one of the PyPy devs on how interested parties can contribute to the development of Numpy on PyPy. Lack of Numpy support is the showstopper for me and a lot of other people in terms of switching over -- almost everybody who wants faster Python is using Numpy in some way or another :-) This is something I would be really interested in working on.
- cdavid 15y agoNot really, numpy depends too much on cpython internals. There is an interest in rewriting numpy for pypy, but I am not sure whether this is the best way of doing it. From what I understand, the choice is between better pypy's compatibility with C extensions (easier, but slower because of cpython emulation in pypy) vs rewriting it for pypy (harder, but would benefit more from pypy).
- nickik 15y agoI'm not really intressted in the Python interpreter that pypy is but the other part pypy (the toolchain) is maybe the best thing since sliced bread. I have the plan to start working on the scheme implmentation. The thing I don't really like about the project is that it has one name for two things. I can understand how that came about historicly but I think the should make two names out of it.
- kingkilr 15y agoWe've started referring to it as the "RPython translation toolchain" which will hopefully reduce confusion.
- nickik 15y agoYou should think of a snappier name. Other than that keep up the good work. I'm atm reading all the pypy papers, very cool.
- fijall 15y agoyou should have a look at scheme interpreter that was written already maybe: https://bitbucket.org/pypy/lang-scheme/overview https://bitbucket.org/pypy/lang-scheme/overview