Python performance

[Steve Holden]

see_plus_plus at my-deja.com wrote:
> 
> Until somebody writes a chess program in Python or Lisp to beat the
> chess world champion, performance is a big question with those two
> lamguages.
> 
Well of course.  The capitalist hyenas are investing huge amounts of
money into automated chess play because they sense it will be the next
killer app.  Chess play is not a relevant application when discussing
the "best" (a value-loaded word) way to perform everyday programming
tasks.  Why not look at database or reporting applications, which are
far more common, and therefore presumably more "useful"?  Besides which,
for many modern commercial applications, I/O throughput is rather more
significant than CPU speed.

For interactive programs, flexibility in interfaces is significant.

> The program running on the IBM Deep Blue that beat the best chess player
> was not written in Python/Perl/Tcl/etc., neither in C++ nor Java, but in
> the abandonning C.
> 
And the program which beat the world checkers champion years before was
written in assembly language.  What does this prove?  When Python has been
around for as long as C has then it may stand a chance of getting closer
to it in terms of performance.  But surely C, which is at best a kind of
advanced assembly language with a good range of libraries, just happened
to be the best language for the program approach taken by the Deep Blue
designers.  Or they simply knew no better (unlikely).  For computationally
intensive problems, programmers will always want a language which puts as
little as possible between them and the CPU, and they will hack around
defects in data structure representation for the sake of efficiency.  Why
else would FORTRAN have been so popular for so long?  Quite simply, there
was nothing to equal it in raw arithmetical power: it was a good language
for a large and significant problem domain.

> That program did not crash during the competition, it thinks much faster
> and much deeper than Kasparov.
> 
So, let me get this straight: you want to argue from one single, rather
specialised, application, that C is clearly the best language for a whole
class of problems? Or even ALL problems?  Do me a favor ...

And Deep Blue "thinks"?  Please don't anthropomorphise: it "thinks" when it
computes chess moves about as effectively as I "fly" when I'm in an
aeroplane.  Put me at a thousand feet with nothing but my arms and legs
and the birds will soon be seen to be rather better flyers than I am.

Similarly, put Deep Blue out in Times Square and ask it to get to the
Empire State building, and you will observe that what it does cannot
really be described as "thinking" except in the most specialised sense.
Kasparov, however, would be able to use (verbal and non-verbal) language
skills to help him navigate.  Without getting into arguments about what
thought really IS, Deep Blue wouldn't stand a chance of passing the Turing
test: it's far too specialised a machine to be any kind of thinker.

> cpp

A reasonably fair attempt at self-evaluation from
what would appear to be a troll :-)

Choice of language is important in a number of contexts.  I will select two
which I see as at opposite extremes:

  1.	The "throwaway" program, written to run once and answer a particular
	question.  For such programs, the appropriate choice of language is
	the one which gives the shortest development time consistent with
	acceptable performance.  Programmer time is MUCH more important
	than computer time here, and there is no point optimizing code
	which will be thrown away.

  2.	Mass-market numerical computations.  Here the CPU-time tends to
	dominate, and it's worth the programmer making a LOT of effort to
	increase execution speed, since optimizing performance will give
	benefits to all users - they wil get their answers sooner.

In between these extremes (and I am misrepresenting the problem space as
one-dimensional, whereas in fact it has many dimensions with different
significances to different people) there are a huge number of problems
where computational efficiency is significant but not necessarily
predominant.

Some systems are built in a mixture of languages precisely because no one
language is good at everything.  Guess what, people are pragmatists: they
choose what they do BECAUSE IT WORKS!

Representational flexibility is an important aspect of programming
languages, since usually we are attempting to model some aspect
of the real world when we build computer-based systems.  Python's object-
oriented nature and dynamic typing give it a high degree of flexibility,
and I would suggest THAT is one of the principal reasons it is enjoying
the popularity it does. 

Nobody in the Python community is suggesting it's the best language to write
chess playing programs in.  But it might actually be a good language to direct 
strategy, even though a more efficient language will beat it for multi-ply
tactical calculations.

Most significantly, the Pythonista tends to be a realist with few pretensions
to world domination, and so even rather narrow arguments from the devotees
of other languages tend to be met with educational fervor rather than flame
wars.  Just trying to help in my novitiate way.  Have a nice day.

regards
 Steve

> 
> 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.
> >
> > I realize this is a big subject, and that many of you Python wizards
> out
> > there have thought a good deal about it, and I don't want to open a
> can of
> > worms, but if someone can summarize the issues, that'd sure be helpful
> to
> > someone who wants to understand them.
> >
> > Thanks.
> > --
> > Cheers!
> > / Chris Ryland, President / Em Software, Inc. / www.emsoftware.com
> >
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
"If computing ever stops being fun, I'll stop doing it"