On Thu, Mar 3, 2011 at 10:43 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Sun, Feb 27, 2011 at 7:15 AM, n00m <n...@narod.ru> wrote: > > http://www.spoj.pl/problems/TMUL/ > > > > Python's "print a * b" gets Time Limit Exceeded. > > If speed is the only thing you care about, then you can forget about > fretting over whether 2.5 or 3.1 is faster. You're using the wrong > language to begin with. > Actually, in my current project, Pypy's performance is bordering on stellar. It's much faster than CPython 2.x, CPython 3.x, CPython 2.x+Cython, CPython 3.x+Cython, CPython 2.x+Psyco or Jython. Interestingly, CPython 3.x+Cython (pyx) is the next best. I've placed a graph contrasting Python runtime performance for this project at http://stromberg.dnsalias.org/~dstromberg/backshift/ Yes, of course, this is just for this one project, and only for this project's critical section (which I'm optimizing relatively early to decrease the duration of my lengthy tests). Yours would almost certainly give a different graph. The problem being solved is a byte-at-a-time variable-length, shift-resistant blocking (checksum). BTW, about runtime vs compiler optimization: A JIT can theoretically give better performance than an optimizing compiler, because the optimizing compiler only has access to compile-time info, while the JIT has access to what's really happening, as it happens - so for example, branch prediction can be more accurate with the JIT, once you burn past the JIT'ing overhead.
-- http://mail.python.org/mailman/listinfo/python-list