On Mon, Aug 15, 2011 at 2:05 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi David,

On Sat, Aug 13, 2011 at 8:14 PM, David Naylor <naylor.b.david@gmail.com> wrote:
> So, it appears pypy is failing to speed up this contrived example...

I think that it is expected, because the hash is computed entirely as
pure Python code in the case of PyPy (doing integer arithmetic with
overflow checks) whereas it is written in C in the case of RPython.  I
find it rather good that we get overall close to the speed of CPython,
given that we just have datetime.py...  Try using datetime.py on top
of CPython too :-)

More seriously, if we want to be really better with datetime objects,
as opposed to "good enough for now", then I fear we need to rewrite
datetime.py in RPython, like CPython did rewrite it in C.  Or some
intermediate solution is possible too, having an internal class which
implements only basic operations (like hash) and which is subclassed
in pure Python.  But I would happily leave that task to someone with
an absolutely real need for high-performance datetime objects; for me
"good enough for now" is good enough, for now...


A bientôt,

Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

I'd like to express that, unless we have a very compelling reason, we should try to keep more stuff in pure python, as opposed to RPython.  Mostly because it speeds up translation ;) (also easier to test, easier to write, etc.).

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero