A happy new year to all involved! I will be flying back to Texas tomorrow, and hopefully caught up on work enough to try to start contributing a little again by next weekend. Debugging these sorts of benchmarks is a task which, as Alex mentioned, he and I actually made some headway on, so this has given me a (possibly quite false) sense of confidence about my understanding of a few sections of the PyPy code. I'll check back later in the week to figure out what I should consider working on, but I think there are plenty of little bugs and code cleanup tasks available for my amusement. In addition to those tasks, I have been thinking about the dict object implementation. If no one else is working on this, I might have a go at creating one which is somewhat more efficient. Pat
-----Original Message----- From: Alex Martelli [mailto:aleaxit@yahoo.com] Sent: Friday, January 2, 2004 09:42 AM To: 'Seo Sanghyeon', pypy-dev@codespeak.net Subject: Re: [pypy-dev] Pie-thon benchmark
On Wednesday 31 December 2003 09:39 pm, Seo Sanghyeon wrote:
Happy new year, pypy-dev!
And a happy new year to you!
I think it's quite important at this stage to have pypy run as much benchmark and testing CPython code as feasible (I spent the Amsterdam sprint mostly working on that, mostly pair programming with Pat Maupin, and Laura and Jacob also worked a lot on adding and fixing built-ins -- as a result we now have versions of pystone and of the CPython unit tests for built-in types and functions running under pypy, though quite a bit of the unit tests has had to be commented out to get there -- plenty of things we can't fix, or can't fix yet / right now, or, like complex numbers, don't really want to spend lots and lots of energy at this stage). So, I heartily approve of your work on pie-thon!
For PyPy, I used `time python py.py -S b?.py'. To make relative import work I prepended `PYTHONPATH=.' for b4.py and b6.py.
b0.py: error __new__() takes exactly 4 arguments (1 given)
Hmmm -- guess we gotta work on making some of __new__'s args optional!
b1.py: error maximum recursion depth exceeded
(No hypothesis here).
b2.py: real 1m25.725s (250x slow)
Wow -- more commonly the speed ratio is observed to be in the thousands (e.g. the fastest laptop at the sprint got 3 pystones/sec in pypy, vs I believe 50,000 pystones/sec in CPython 2.3.3).
b3.py: error __new__ multimethod got a non-wrapped argument
Ouch -- this is sure to be a serious coding error somewhere in pypy.
b4.py: error (this one imports and uses b0.py) b5.py: error global name complex is not defined
Right, we haven't worked on complex... there's some code for complex but no work has been spent making it work as a builtin type, AFAIK.
b6.py: error unbound method must be called with instance as first argument
More comments on b6.py: it took 22 minutes(!) to crash. It printed 42, 1000041, 999999, 49999950000, and finally crashed at `d = dict.fromkeys(xrange(1000000))'.
Ah, yes, this is a known issue -- we can't yet expose classmethods from built-in types. We do have classmethods, for user-coded types, we just haven't yet gotten around to installing fromkeys as a classmethod into builtin type dict -- so it looks like a normal method instead.
Alex
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev