Python performance

[Michael Hudson]

claird at starbase.neosoft.com (Cameron Laird) writes:

> In article <jQ%w4.238$m4.7517 at news>, Chris Ryland <cpr at emsoftware.com> wrote:
> >The recent Python-for-Lisp-ers note and other recent notes have brought up
> >Python performance.
> >
> >I'm just curious (being an old language hacker for 30+ years but new to
> >Python): why is Python performance ultimately any worse than Lisp?
> >
> >Is it because there's only been one major implementation effort so far, and
> >so people haven't had a chance to learn the techniques required to make it
> >run fast, while Lisp has had 30+ years to mature?
> >
> >What's so different about compiling Python vs. Lisp? Some Lisp compilers
> >have gotten quite good over the years.
> 			.
> 			.
> 			.
> There have, in fact, been several Python implementations already <URL:
> http://starbase.neosoft.com/~claird/comp.lang.python/python_varieties.html>.
> They look "major" to me, although I can imagine you might be setting the
> boundaries in a different place from me.

They don't rate major when compared to cmucl, Allegro Common Lisp or
Harlequins LispWorks.  Not by a long shot, not yet.

> Performance is an explicit motivation for most of the alternative
> Pythons.
> 
> Guido regularly professes a lack of interest in performance.  At
> least part of the time, he's using that to attract attention to his
> profound belief in the importance of correctness; he works very, very
> hard to get Python "right", and, from what I can see, has faith that
> performance will follow and/or can be left to others.

I don't want to disagree with this pragraph ...

> One difference between Python and LISP is that with Python, as with
> most its contemporaries, one has more of a feeling that the performance-
> pertinent action is happening in the libraries rather than the language.
> 
> My conclusion:  Python performance can be (roughly) as good as LISP's.

... but this is just not true (in some areas).  Writing numnerical
code springs to mind, 'cause that's what I've been doing in the last
few days.  You just can't make Python fast for this (at present).
(and to those that say "implement those bits in C": go away, that's
not the point I'm making here).

I ended up translating it to Haskell.

> It is, already, for the domains that matter most to the big players of
> the Python world.

This is a bit of a chicken and egg situation; I'd dearly love to use
Python for my number slinging, but it's prohibitively slow at the
moment, so people don't use Python for this.

I hope that one day I will be to write numerical code in Python and
have it match in performance what I can do with Common Lisp or Haskell
(or ...).  Or get within an order of magnitude.

Cheers,
M.

PS: Before some bright spark suggests I use NumPy: I've been doing
number theory ...

-- 
very few people approach me in real life and insist on proving they are
drooling idiots.                         -- Erik Naggum, comp.lang.lisp