[pypy-dev] Pie-thon benchmark
pmaupin at speakeasy.net
Sun Jan 4 13:42:40 CET 2004
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
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
> -----Original Message-----
> From: Alex Martelli [mailto:aleaxit at yahoo.com]
> Sent: Friday, January 2, 2004 09:42 AM
> To: 'Seo Sanghyeon', pypy-dev at 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
> > 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
> > 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.
> pypy-dev at codespeak.net
More information about the Pypy-dev