I'm happy with Python 2.5

Dan Stromberg drsalists at gmail.com
Sun Mar 6 14:22:00 EST 2011


On Thu, Mar 3, 2011 at 10:43 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:

> On Sun, Feb 27, 2011 at 7:15 AM, n00m <n00m at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110306/15b921b5/attachment-0001.html>


More information about the Python-list mailing list