PyPy Blog

The PyPy folks are working on a JIT, apparently with great speedups. They've been detailing their work on their blog: http://morepypy.blogspot.com/ Also, are JavaScript and Python really that dissimilar? Everyone's working on tracing JITs for JavaScript now, with great results.

For performance and algorithms the implementations at http://shootout.alioth.debian.org/u32q/python.php and pay attention to the different benchmarks. Also all RPython code coming from pypy, sometimes shown in http://morepypy.blogspot.com/ They are reimplementing all the C modules and doing a great job. The new implementations are of course closer to current best practices in python. Enjoy.

Love seeing the triple release. PyPy has come a long way on Python 3 since Py3k [1] and Fulcrum [2] and great to see a non-EOL Python 2 out in the wild. [1]: https://morepypy.blogspot.com/2012/01/py3k-and-numpy-first-stage-thank… [2]: https://morepypy.blogspot.com/2014/06/pypy3-231-fulcrum.html

Python isn't perversely dynamic, no more so than Self which was running within a factor of 2 of C like 30 years ago, and PyPy optimizes Python just fine. The major stumbling block is that the C API unintentionally sucks and requires lots of work to support https://morepypy.blogspot.com/2018/09/inside-cpyext-why-emulating-cpyt… LuaJIT is a great example of how experimentation and the right tradeoffs can give you a faster language runtime without a huge effort but it's not at all a great example of a highly optimizing compiler. There's no "map" or "hidden class" optimization in LuaJIT, for example, and getting good performance means avoiding repeated table lookups.

In related news, PyPy now appears to consider their Python 3.6 interpreter released, if I'm understanding this correctly: https://morepypy.blogspot.com/ While I'm happy this work is being done, waiting over a year from a 3.x release for an ~4x speedup from PyPy is kind of a bummer. Most of my work is already on 3.7.

yeah - because people dont go to the homepage. what gets tweeted out is this blogspot page (including here on HN). So people check out the nice blog post and see a donate link on the left of https://morepypy.blogspot.com/ and then go ...hmm, looks shady. Not many read the blog post, then go to Google, search for pypy and then click the link and then donate. Fundraising is not an easy process - there is an aspect of sales here. Blogspot may be easy.. but its not good branding. And that was my point - cos I want them to succeed.

Excellent! It hadn't occurred to me before that PyPy's parser error messages could be different from CPython's; I must have forgotten that they rewrote the parser [0]. [0] https://morepypy.blogspot.com/2009/08/pypy-gets-new-compiler_25.html

I've also been creating a programming language recently [1]. I'd recommend looking into the pypy tool chain. It makes it pretty easy to hack together a decent interpreter (that JITs). That and rply for the front-end gives you enough tooling to be dangerous. Here's a good tutorial [2]. [1] https://github.com/DanielWaterworth/plastic [2] https://morepypy.blogspot.co.uk/2011/04/tutorial-writing-interpreter-w…

> "I'll believe it when I see it". You may be interested in this... "Leysin Winter Sprint (20-27th February 2016)" "STM (Software Transaction Memory), notably: try to come up with benchmarks, and measure them carefully in order to test and improve the conflict reporting tools, and more generally to figure out how practical it is in large projects to avoid conflicts" http://morepypy.blogspot.co.uk/2016/01/leysin-winter-sprint-20-27th-fe… > "Nor do I recommend that you use it as part of your advocacy." I'm an advocate for F#, but I'll encourage the progress of any open source language, strong competition is good for the field as a whole. The question isn't 'Why can't Python be fast?' but rather 'How fast can Python be?', the difference is a difference in attitude.

BrainFuck is a great place to start because it's pretty simple. I started with this post on the PyPy blog: http://morepypy.blogspot.co.uk/2011/04/tutorial-writing-interpreter-wi… This repository helped as well: https://github.com/thoughtpolice/bf-pypy Getting a basic interpreter working wasn't hard, but I attempted to add a few of the optimizations listed here[1], which meant adding some form of AST and stuff to manipulate it. This is where I got a bit stuck with regards to performance as some of my optimizations meant the program should have been faster, but instead it slowed down. 1. http://calmerthanyouare.org/2015/01/07/optimizing-brainfuck.html

PyPy really closes the speed gap. The latest PyPy 2.5 release uses pinning to pass pointers between the C layer and PyPy greatly improving IO performance [1]. I've noticed this in a project I've been working on holding open large amounts of concurrent connections (> 100k at a time), PyPy has been completely competitive with Go, and actually using less memory. Yes, it's not as fast as a Java/C+ version, but with PyPy its more like 2-5x slower, not 10-100x slower which really changes things. [1] http://morepypy.blogspot.com/2015/02/pypy-250-released.html

Worth pointing out that on PyPy you effectively get this for free.. http://morepypy.blogspot.co.uk/2010/11/efficiently-implementing-python…

The original blog post they did on STM is well worth reading, especially if you're not familiar with the python GIL and STM. http://morepypy.blogspot.com.au/2011/08/we-need-software-transactional…

I'm looking into this and even talked to Jeremy Ashkenas about it last year. Unfortunately, I've not had the time to get any further than reading the PyPy tutorials: http://morepypy.blogspot.nl/2011/04/tutorial-writing-interpreter-with-… However, I hope to have some time in the fall in which to pursue this. If anyone else takes it up in the meantime, I'd love to contribute. Interestingly, a native CoffeeScript interpreter already exists: Poetics, which runs on the Rubinius VM. Very cool project. Another very interesting CoffeeScript project is the MoonScript project, which compiles a variation of CoffeeScript into Lua.

I was reading an article about implementing an interpreter for Brainfuck in PyPy, and when the example code for some simple Brainfuck programs came up, I just stared. I really fail to see how one would go about programming just about anything in that language. (Here's the article in case anyone is interested, a pretty good read IMO: http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with…

Rumor has it that Haswell-EP is going to bring 16 core, 32 threads CPUs (up from the current 10 core, 20 thread chips), allowing for 128 threads on a 4 socket systems. Which is to say, we're actually not that far way from the title of this site becoming quaint, like Teradata does today - assuming Moore's law holds for a while. Interestingly, and not coincidentally, Haswell is also the first chip that will support hardware transactional memory, which should speed efforts like PyPy's STM, which enables you to write code without manually locking anything. http://morepypy.blogspot.co.nz/2012/06/stm-with-threads.html Great submission though - bookmarked!

That is the goal of the effort (see the pypy blog for the history of the effort, http://morepypy.blogspot.com ). But as noted in TFA, it is currently very, very slow, so no the problem is not solved, creating a very very slow GIL-free interpreter has been possible for a long time, just... very very slow so not acceptable. Also it's not CPython. Technically, if you want the GIL to be gone on Python in general you can already use IronPyton or Jython which do not use a global interpreter lock.

There are two blog posts as of why: http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-and-roadmap.… http://morepypy.blogspot.com/2011/05/numpy-follow-up.html It's not possible to do cool stuff with reusing - like parallelizing expressions etc. The architecture as it is now already can score 2x wins over original numpy with array expressions and we expect it to get only better with SSE and more parallelizing. This requires reimplementing numpy.

http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html "Translating RPython to C is pretty cool, but one of the best features of PyPy is its ability to generate just-in-time compilers for your interpreter. That's right, from just a couple hints on how your interpreter is structured, PyPy will generate and include a JIT compiler that will, at runtime, translate the interpreted code of our BF language to machine code!"

The Python community celebrated April Fools' Day, too (even though they were rather easy to figure out, I liked them for their creativity): "Trying to get PyPy to run on Python 3.0" <http://morepypy.blogspot.com/2008/04/trying-to-get-pypy-to-run-on-pyth… If you followed PyPy's politics in the last few months, the headline's already yelling "APRIL FOOL" at you. I liked the "Automatic Program Reversion on Intermediate Languages" (APRIL). ;-) "psychotic -- Pure Python code optimizer" <http://code.google.com/p/psychotic/> The source is definitively worth a view.

Thanks for that link. In that video Travis Oliphant is proposing "EPython", the goal of which is to allow multiple Python implementations to share the same extensions. Currently NumPy and other extensions are very tightly coupled to CPython. But I just saw a very similar project by the name "HPy" on the PyPy blog: https://morepypy.blogspot.com/2019/12/hpy-kick-off-sprint-report.html The idea of HPy was born during EuroPython 2019 in Basel, where there was an informal meeting which included core developers of PyPy, CPython (Victor Stinner and Mark Shannon) and Cython (Stefan Behnel). The ideas were later also discussed with Tim Felgentreff of GraalPython, to make sure they would also be applicable to this very different implementation, Windel Bouwman of RustPython is following the project as well. And they even say NumPy is a major use case: Eventually, we will also want to try to port parts of numpy to HPy to finally solve the long-standing problem of sub-optimal numpy performance in PyPy. Anyway there's nothing wrong with competing projects. Progress gets made faster that way. But I guess it's weird that the video and the blog post have very similar dates but don't mention each other. The problem they're solving seems essentially identical, and they even mention all the same Python interpreter implementations.

PEP 412 makes __dict__s more memory efficient than they were before, but not more efficient than no __dict__, which is the point of __slots__. The following program demonstrates the difference. Note that it lowers the available address space to 1GB so that memory exhaustion occurs sooner, and thus only works on UNIX-like systems that provide the resource module. import resource import sys class WithoutSlots: def __init__(self, a, b): self.a = a self.b = b class WithSlots: __slots__ = ('a', 'b') def __init__(self, a, b): self.a = a self.b = b resource.setrlimit(resource.RLIMIT_AS, (1024 ** 3, 1024 ** 3)) cls = WithSlots if sys.argv[1:] == ['slots'] else WithoutSlots count, instances = 0, [] while True: try: instances.append(cls(1, 2)) except MemoryError: break count = len(instances) del instances print(cls, count) Here are numbers from my laptop: $ python3.6 /tmp/slots.py <class '__main__.WithoutSlots'> 5830382 $ python3.6 /tmp/slots.py slots <class '__main__.WithSlots'> 16081964 That's almost 3x more instances with __slots__! This isn't the case with PyPy, though, thanks to a more efficient representation of objects: https://morepypy.blogspot.com/2010/11/efficiently-implementing-python-…

Maybe not "daily", but very frequently: here is a small selection of some of the small sites on my newsblur newsfeed list: [0] http://www.jamesaltucher.com : Much self-pity, but also sometimes quite funny. http://www.astrobio.net/latestnews_rss/news.xml : Is there life on other planets? http://kaygun.tumblr.com/ http://www.friday.com/bbum : Coding, hardware projects, generally interesting. http://bestyoucanbe.blogspot.com/ : Insights into the education system in regard to the raising of his neurologically non-typical son. http://blog.lmorchard.com http://ex-muslim.org.uk : Oppression of atheists in the Muslim world. http://clojurefun.wordpress.com : Clojure! http://scientopia.org/blogs/goodmath : Bad science, denialism. http://blog.willbenton.com : Music, logic, programming, etc. http://www.groklaw.net : Maybe not "small"; detailed analysis of important legal cases. http://hicksdesign.co.uk/journal : Web design. http://www.holovaty.com/ : "I'm co-creator and co-Benevolent Dictator For Life of the open-source Django Web framework" http://prometheus.med.utah.edu/~bwjones : Combines talented photography, photoessays, and study of the retina. http://lee-phillips.org : I regularly check my site to see if it's still working. http://chronicle.com/blogs/linguafranca : Language issues; can be amusing or stupid. http://freethoughtblogs.com/maryamnamazie : Freedom for women in the Muslim world. http://math-blog.com : Infrequently updated, but often…

Quick how-to: 1. (optional) install PyPy "JIT compiler" binaries [0] 2. get and extract the PyPy source[1] from bitbucket release packages, which includes the RPython translator, written itself in Python and, although working on CPython, best run under PyPy as installed on step 1. 3. write a (R)Python module including a def target returning the entry point function[2], and call the translator upon your module, like so: python ./pypy/pypy/translator/goal/translate.py example2.py I wish getting the translator was more 'packaged' and did not involve getting the whole PyPy source but I hear this is in the works, and it is reasonably easy already. The hardest part is actually figuring the translator is not part of PyPy binary release, and that it's available straight from bitbucket. [0]: http://pypy.org/download.html [1]: https://bitbucket.org/pypy/pypy/get/release-1.9.tar.bz2 [2]: http://morepypy.blogspot.fr/2011/04/tutorial-writing-interpreter-with-…

> I was mostly replying to your assertion that "that's not even remotely how strcmp is implemented", which, for most definition of "even remotely", is false. eglibc's SSE2 implementation of strcmp is just over 5k of machine code, whereas the simple implementation compiles to 56 bytes on x64-64. That was my definition of "not even remotely." I did not mean to imply that it was a fundamentally different algorithm, only that it was a far more sophisticated and optimized implementation of the same algorithm. My apologies if this was unclear or appeared overstated. > That's a tautology at best, and meaningless at worst. By "these abstraction possibilities" I meant the ones you mentioned, which is true. > And similarly, any Python application that requires (insert some uncommon requirement ..) can do what C can with the same kind of help that strcmp() gets - by delegating to the layer that does it best. That's great and I fully support that. What I am arguing against is high-level language cheerleading that discounts the importance of C (or assembly for that matter). Since you mention PyPy, I have to say that their PR is some of the worst in this regard; some of their "faster than C" claims are actively misleading, like this one that benchmarks some generated string formatting code against sprintf() (which re-parses the format string every time): http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-strin…

Hi Alex, mine might be a minority view/request, but I think RPython is an interesting and useful language in its own right and should be standardized and highlighted. Possibly separated out with a website of its own to emphasize its existence. When I write Python it is rarely the case that I assign values of different types to the same identifier, or add attributes to a class outside of its definition, or monkey patch a module. In other words most of the time I am not really making use of the dynamic properties of the language. In this scenario Python is a language that saves me "finger typing", and I do not needs its dynamic typing as much. I am more than willing, in these scenarios, to trade some of that unused dynamism for better performance. I think there might be others who are similarly inclined. The one thing that I miss in RPython is generators. Is there a particular difficulty because of which it was left out ? I assume so, because all the statically typed variants of Python leave it out as well, but I do not have enough background to know what that difficulty might be. The other is Numpy :) but I believe you guys are working on that. @wbhart A lot of what you ask is answered in some detail in the PyPy blog http://morepypy.blogspot.com/ I wouldnt call PyPy less well known though.

If you're going the pure Python route, don't forget to try PyPy[1], an alternative JITed implementation of the language. A seriously underrated project, IMHO. Most time it speeds up execution by a factor of 2x-4x, but improvements of about two orders of magnitude are not unheard of. See for example [2]. Numeric, long-running code shoud suit PyPy optimizations well. [1] https://pypy.org/ [2] https://morepypy.blogspot.com/2017/10/how-to-make-your-code-80-times-f…

I've gotten rr to work with very specific builds of rpython before but you might be surprised at the ongoing interest: https://github.com/python/devguide/issues/1283 https://morepypy.blogspot.com/2016/07/reverse-debugging-for-python.htm… https://github.com/mesalock-linux/mesapy/blob/mesapy2.7/README.md

Looks interesting. I see you're implementing in python - did you consider rpython/pypy? See eg: https://rpython.readthedocs.io/en/latest/getting-started.html https://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-wit… https://rpython.readthedocs.io/en/latest/examples.html

PyPy has a JIT because using Python as the implementation language made it simple to build a runtime generator instead of a single runtime implementation, so RPython (the underlying PyPy tech) can generate a JIT and non-JIT runtime from the same source code. Conversely, the CPython team doesn't have the resources to make a JIT runtime the bespoke way that's more typical for these projects. https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html