On Mon, Aug 15, 2011 at 2:05 AM, Armin Rigo <ar...@tunes.org> wrote: > Hi David, > > On Sat, Aug 13, 2011 at 8:14 PM, David Naylor <naylor.b.da...@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
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev