6th week of Schemepy: mzscheme-3m, guile-1.6 and others

June 7, 2008 – 12:16 am

As I said in the last status report, although I finished the mzscheme backend, I found the currently commonly used version is in fact of another memory model. My original code was written against the CGC memory model, so I need to re-implement part of the backend to adopt the new 3m model.

At first, I have no idea of how to implement it totally. The mzscheme GC is moving the memory, I need to register all local pointers to it — but it is unrealistic for a Python program. So I asked for help on this. I got answer from both the schemepy mailing list and the mzscheme mailing list — use immobile.

immobile is a handler to the GC-able pointer which will need to be explicitly freed. When mzscheme moves the objects, it will update the immobile automatically. It is exactly the solution I was looking for. So I quickly created a branch mz_3m and started hacking the original CGC code. Later, I got a mzscheme backend that works with 3m. At first, I guess it might be significant slower than the original CGC version because every pointer now needs one more layer of indirection. But the benchmarks showed that the performance is nearly not affected. :)

There are also other changes in this week:

  • My guile backend now is guile-1.6 compatible. But Windows support is still not added yet.
  • I created a uniformed document for the API of all backends.
  • I write some benchmarks for testing specifically the performance of the backend wrappers. i.e. the performance of conversion Python value to Scheme value and vice versa.
  • A repl method is added the VM to get an interactive Scheme shell conveniently.
  • etc.

I have looked at the timeit module a bit, but still not use it in the benchmark utility yet. Maybe one reason is that it only measures the elapsed time. Sometimes it is better to look at user time and system time separately (e.g. when lots of time is spent on IO). timeit disabled the Python GC by default before running the benchmark. This is generally a good choice, but I guess when comparing the performance of different backends, the GC is better to be taken into consideration.

In fact, I tried several times to take both the tp-server/tp-client related task and the PyPy Scheme related task but failed to get started.

I try to read Some general thoughts on ship design in Stars. Then I find the rules of 4x games are so complicated (and fairly boring) to me. In other words, it seems to me that to learn how to play such a game is not easier than to lean how to write a Schemepy backend. :( A friend of mine likes playing Star Craft very much. I’m not sure whether it is a similar game to TP, but I guess I can ask him for some help.

Another difficult is the PyPy Scheme. I looked at some of the code. The parser is fairly simple, but it depends on the PyPy parser heavily. I’m not quite sure how much work would needed to write a parser that fits the PyPy Scheme’s original code, especially when it comes to something like error handling during parsing. And the PyPy parser itself seems to depend on other parts of the PyPy library.

I also considered another choice — implement a fresh Scheme VM. However, we already have pyscheme and other similar implementations. None of them are of very good performance. But while implementing a toy Scheme VM is not too hard, making a high-performance and R5RS-compatible one is really hard. I think I would go through the last 2 chapters of SICP and discuss on the mailing list before making any choice.

Post a Comment