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