Hey Collin, Thanks for the good answers so far!
On Thu, Jan 21, 2010 at 21:14, Collin Winter <collinwin...@google.com> wrote: > We used to run the Mercurial correctness tests at every revision, but > they were incredibly slow and a bit flaky under CPython 2.6. Bazaar's > tests were faster, but were flakier, so we ended up disabling them, > too. We only run these tests occasionally. Oh, how I know how slow the tests are. I think the flakiness should be limited to only a few tests (notably the inotify ones), but I guess you may have enough correctness tests going to not have to test everything at every revision. > I can definitely work on that. > http://codespeak.net:8099/plotsummary.html should give you a quick > starting point for PyPy's performance. My reading of those graphs is > that it does very well on heavily-numerical workloads, but is much > slower than CPython on more diverse workloads. When I initially > benchmarked PyPy vs CPython last year, PyPy was 3-5x slower on > non-numerical workloads, and 60x slower on one benchmark (./perf.py -b > pickle,unpickle, IIRC). Yes, it makes sense from what I've seen to suppose that PyPy so far has been focused more on numeric tasks, rather than more common/diverse usage. Nevertheless, I think the PyPy JIT has come a long way in the past 6 months or so (there should be a PyPy 1.1 release relatively soon, I think), and I think it makes sense at least to take this into account in a kind of landscape section. > My quick take on Cython and Shedskin is that they are > useful-but-limited workarounds for CPython's historically-poor > performance. Shedskin, for example, does not support the entire Python > language or standard library > (http://shedskin.googlecode.com/files/shedskin-tutorial-0.3.html). Perfect, now put something like this in the PEP, please. ;) > Yes, you could implement a tracing JIT with LLVM. We chose a > function-at-a-time JIT because it would a) be an easy-to-implement > baseline to measure future improvement, and b) create much of the > infrastructure for a future tracing JIT. Implementing a tracing JIT > that crosses the C/Python boundary would be interesting. Okay, this (combined with Reid's later post about it being a good 3-month project) sounds promising enough. Cheers, Dirkjan _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
