Re: PEAK-Rules and PyPy

On Wed, Oct 17, 2012 at 6:13 PM, Alain Poirier <alain.poirier-HPmRmcG/[email protected]> wrote:
> I tested today several applications with predicates dispatch rules, for
> web stuffs and complex business workflows and they all ran fine, without
> any problem (I didn't yet benchmark them).

Well, on my machine, the tests run six times slower under PyPy than
under CPython 2.7.  However, this isn't due to the changed dispatcher;
even using the slower dispatcher, the tests still run six times faster
in CPython.  Evidently, something the tests are doing a lot is a lot
slower in PyPy -- it wouldn't surprise me if it has something to do
with the use of id() and/or garbage collection.

> That's really great, thanks.
>
> Now I can only hope for an official release ;)

Done as of the current checkin (rev #2713).  PyPy can now run
PEAK-Rules' full test suite without errors, now that I've added
workarounds for PyPy bugs #1292 and #1293.  (Which I just filed: #1292
is a difference in repr() of classes defined in doctest, and #1293 is
a docstring corruption when a function's code is modified before its
docstring is read.)

The only other change was the linear-search dispatcher, which is now
activated if __pypy__ is a builtin module of the running executable.
Otherwise, the "computed goto" hack is still used.  The linear search
probably won't add too much overhead in most cases; it's most likely
to affect GFs with lots of complex predicates, like the ones internal
to PEAK-Rules' own predicate dispatch system.  ;-)  (That is, it's
more likely to affect the sort of GF's you see in compilers,
optimizers, and other pattern-matching heavy applications.  Not so
much for simple multimethod and ranged lookups.)