python performance

[Alex Martelli]

"bruce" <davidlam at cableinet.co.uk> wrote in message
news:J8fn6.756$me1.378895 at news2.cableinet.net...
> Can  anyone comment on the speed of Python programs under Windows?

"Pretty good" comes to mind, if you're wise in leaving the
low-level, time-consuming stuff in C modules, as you say:

> I am interested in using Python as a embedded game scripting language.
> Amongst other things, I want to doing AI, but not the low level routines
> like path finding.

Some very rough tests among interpreted languages on a Win32
box suggest that Python is roughly in the middle of the pack --
generally better than VBScript or JScript, not quite as fast
as Perl, Java, or Visual Basic (but still quite comparable, in
either direction).


To take a maybe-non-typical case -- one of my personal areas
of interest is in the theoretical underpinnings of contract
bridge (cfr my article "How Shape Influences Strength", in
the Jan and Feb 2000 issues of the Bridge World magazine; also,
http://www.fenx.com/alex/ for my vague ideas about 'PyBridge').

I am currently running a double-dummy simulation of play at
suit and no-trumps with strong balanced hands facing each
other; it runs in the background in an oldish box (Pentium II
266 MHz, Win2000, 192M RAM) and the current run has so far
simulated 182*24*20*2 = 174720 plays, in 249055 elapsed
[wall-clock] seconds (it's about 1/5th of the way through --
and as soon as it ends, I'll start yet another run; I need
many, MANY million simulated hand-plays for statistical
analysis of the results to mean anything).  Given how time
consuming it is, I did go through the trouble of carefully
instrumenting and profiling the h**k out of it, as well as
architecting it with checkpoints/restarts (wouldn't want a
power outage of something to set me back to ground zero...),
etc.

Which makes it easy for me to tell how much of that time
goes into the (irreducible) demands of the double dummy
simulation engine itself (part of the GIB commercial product --
I only wrote the interface letting Python control it [actually,
the interface exposes it as a COM object, and Python controls
it via win32com, but that's a minor difference]), and how much
into everything else -- generating and culling the hands,
periodically checkpointing, collecting and emitting statistics
about what is going on (including timing measurements and
reporting), etc.  Specifically: 248798 seconds were so far
taken up by the double-dummy simulation engine itself; _all_
of the other operations, together, therefore account for
257 seconds, a bit more than 1 part in 1000 of total elapsed
time.  So, _of course_, the engine (and the COM interface
that lets Python control it) are in carefully-coded, hand
optimized C/C++ -- and _all_ of the rest is in Python.  If
the Python parts were recoded and optimized by a factor of
10, or 100, still, by Amdahl's Law, I would not notice
(literally).

>From time to time I remote-copy the checkpoint and result-
archive files to another machine so I can run some Python
scripts to analyze and summarize some statistics so far.
Typical times for these analyses are a few seconds (with
pure-Python coded scripts) for a few dozen thousands
plays, for each kind of analysis I've tried (I'm still
looking for the ideal C-coded extension to use to do it
more speedily when I'll be running the analyses on many
millions of simulated plays -- taking a minute or so per
each analysis-run in pure-Python is acceptable, but if I
could cut it down to, say, 10 seconds, I wouldn't mind:-).


I would expect similar ratios on many apparently dissimilar
tasks -- simulations and raw number-crunching done in
C, C++, or Fortran, taking huge amounts of time; all of
the directing-intelligence, etc, done in Python, taking
a fraction of the time.


Alex