On Mon, Aug 15, 2011 at 2:05 AM, Armin Rigo email@example.com wrote:
On Sat, Aug 13, 2011 at 8:14 PM, David Naylor firstname.lastname@example.org 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...
Armin. _______________________________________________ pypy-dev mailing list email@example.com 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.).