Python VM Summit - Rough Notes

In parallel with the the 2 days of tutorials at Pycon, there are a couple of day long meetings for invited folks active in the evolution of the language itself. Today was the VM summit, which focuses on the major Python interpreter implementations (CPython, PyPy, Jython, IronPython), the current status of each, and where things are likely to head in the near- and long-term. (The Thursday session focuses more on the evolution of the language itself, as well as of the wider ecosystem).

CPython and PyPy both had multiple devs at the summit, IronPython and Jython devs were also there (although IronPython got to share their's with CPython). We also has some Parrot VM folks there, as well as one of the Mozilla Javascript devs - a bunch of issues with VM development for dynamic languages apply across languages, despite differences in the surface syntax.

The notes below are probably too cryptic to make sense out of context, bit will hopefully give the gist of what was discussed. These notes are my interpretation of what was said, and may or may not reflect what people actually meant. Names omitted to protect the guilty (and because I didn't write them down)

Commit rights for other VM core devs
  - good idea
  - did some of this last Pycon US
  - will look into adding more this week

Splitting out the standard library and test suite (again)
  - duplication of effort between CPython/IronPython/Jython/PyPy
  - shared commit rights intended to make it easier near term to use CPython as master, allowing bugs to be fixed "upstream"
  - hg transition should make sharing easier
  - main CPython release will stay "batteries included"
  - open to the idea of providng "CPython minimal" and "standard library" downloads (but much work to be done in defining a minimum set)
  - longer term, may want to separate pure-Python stdlib development from "C skills required" hacking on the CPython interpreter core and C accelerated implementation modules for the stdlib

Speed benchmarking
  - (very cool!)
  - benchmarks originally chosen by Unladen Swallow team
  - PSF may talk to OSU OSL about setting up
  - benchmark multiple versions of CPython, as well as Jython and IronPython
  - currently benchmarks are 2.x specific, may be a while before 3.x can be compared fully
  - may be GSoC projects in:
      - improving backend infrastructure to handle more interpreters
      - porting benchmarks to Python 3
  - can highlight key performance differences between the implementations (e.g slowspitfire vs spitfire-cstringio) download pages
  - should start recommending alternative interpreters more prominently
  - PyPy likely to be faster for pure Python on major platforms
  - IronPython/Jython/CPython still best at integration with their respective environments (Java libraries, .NET linraries, C extensions)

Cool hacks
  - Maciel: pypy JIT viewer
  - Dave Malcolm: CPython HEAP viewer in GDB 7
Parrot VM (and JIT for dynamic languages)
  - target VM for dynamic languages (primarily Perl 6 and Tcl at the moment)
  - loadable operations, loadable object types 
  - dynamic ops were original speed target, now moving towards dynamic types instead
  - exploring reducing number of core ops to make JIT more practical
  - looking into taking advantage of LLVM
  - Unladen Swallow blazed this trail, so LLVM has better dynamic language support
  - PyPy has tried and failed to use LLVM as an effective backend
  - some issues may have been fixed due to Unladen Swallow's efforts, but others still exist (e.g. problems with tail recursion)
  - SpiderMonkey similarly struggles with JIT and dynamic patching issues
  - GNU Lightning and LiveJIT projects noted, but nobody really familiar with them 
  - any future Python-on-Parrot efforts likely to focus on using PyPy frontend with Parrot as a backend
  - proof-of-concept written (for a thesis?) that used .NET as a backend target for PyPy
  - original Python-on-Parrot ran into problems due to semantic mismatches between Perl 6 and Python - reached the limits of the degree of difference the Perl 6 toolchain was willing to tolerate)
Role of the PSF
  - supports Python the Language, not just CPython the Reference Interpreter
  - could use additional feedback on how to better fulfill that role
  - getting the "boring stuff" done?
  - project-based grants, not blanket personal funding
  - project proposals requiring more funds than the PSF can provide are still valuable, as PSF can help facilitate co-sponsorships (however, still a novel concept - only been done once so far).

2.7 to 3.2
  - PyPy just reaching feature parity with 2.7
  - PyPy now becoming far more interesting for production usage
  - treat PyPy Python 3 dialect like a major Python library (e.g. sponsored by PSF)

CPython warnings for reliance on implementation details
  - ResourceWarning was a nice addition (detects reliance on refcounting for resource cleanup
  - non-string keys in class namespaces would be another good candidate for a warning
  - clarifying finalisation-at-shutdown semantics would be nice (but fixing those semantics in CPython first would help with that)


Comments powered by Disqus