[pypy-dev] This Week in PyPy 7

[Michael Hudson]

Better late than never, eh?

Introduction
============

This is the seventh summary of what's been going on in the world of
PyPy in the last week.  I'd still like to remind people that when
something worth summarizing happens to recommend if for "This Week in
PyPy" as mentioned on:

    http://codespeak.net/pypy/dist/pypy/doc/weekly/

where you can also find old summaries.

There were about 110 commits to the pypy section of codespeak's
repository in the last week.


The Sprint!
===========

The last weekly summary was written towards the end of the sprint.
The things we did in the couple of remaining days were written up in
the second sprint report:

    http://codespeak.net/pipermail/pypy-dev/2005q4/002660.html

Apart from continuing our work from the first half of the sprint, the
main new work was implementing __del__ support in the translated PyPy.


IRC Summary
===========

Thanks again to Pieter for this.

**Monday** http://tismerysoft.de/pypy/irc-logs/pypy/%23pypy.log.20051212::

 [00:26] Stakkars says that it is great that pypy does not punish you for
         indirection. He is of meaning that he writes better style in RPython
         than in Python, because the "it is slow" aspect is gone.

**Tuesday** http://tismerysoft.de/pypy/irc-logs/pypy/%23pypy.log.20051213::

 [21:01] Heatsink says that he is doing some dynamic optimizations in CPython.
         This turns into a discussion about the nature of pypy, and Arigo takes
         us on a tour of how pypy and the JIT will interact in the future. A
         good read of general pypy ideas.
 
**Thursday** http://tismerysoft.de/pypy/irc-logs/pypy/%23pypy.log.20051215::

 [10:24] Ericvrp discovers an optimization that makes pypy 6.8x slower than
         CPython on the richards test suite. All if-elses are converted to
         switches. Cfbolz replies that it is time to write a graph
         transformation to implement this optimization officially.


PyPy's Bytecode Dispatcher
==========================

Something that was suggested but never got-around-to at the last
sprint was to modify the translation process so that the bytecode
dispatch loop of the interpreter used a C switch rather than a table
of function pointers.

The bytecode implementation code in PyPy builds a list of functions
that contain the implementation of the respective bytecode.  Up until
a few days ago, the dispatch function retrieved the correct function
by using the bytecode as an index into this list.  This was turned by
the translator and the C backend into an array of function
pointers. This has the drawback that the bytecode-implementing
functions can never be inlined (even though some of them are quite
small) and there always is a read from memory for every bytecode
executed.

During the Gothenburg sprint we discussed and a strategy to transform
the dispatch code into something more efficient and in the last week
Eric, Arre and Carl Friedrich implemented this strategy.  Now the
dispatching is done by a huge (automatically generated, of course)
chain of if/elif/else that all test the value of the same variable.
In addition there is a transformation that transforms chains of such
if/elif/else blocks into a block that has an integer variable as an
exitswitch and links with exitcases corresponding to the different
values of the single integer variable.  The C backend converts such a
block into a switch.  In addition this technique makes it possible for
our inliner to inline some of the bytecode implementing functions
work.  Using the new dispatcher pypy-c got 10% or so faster (though
the *first* time we ran it it was much much faster!  Benchmarking is
hard).

Preparations for EU-review still ongoing 
===========================================

Many developers are still involved in preparations for the EU review
on 20th January.  Reports are being finalized and there are
discussions about various issues that are only indirectly related to
the development efforts (in so far as it provides the basis for the
partial funding we receive).  We probably will only know on the 20th
if everything works out suitably.


-- 
  This makes it possible to pass complex object hierarchies to
  a C coder who thinks computer science has made no worthwhile
  advancements since the invention of the pointer.
                                       -- Gordon McMillan, 30 Jul 1998