benchmarks and questions for new python programmer

[Terry Reedy]

"stormslayer" <demarchi at duke.edu> wrote in message
news:c5f75ecc.0405170409.59f8f54 at posting.google.com...
> Thanks for all the help.  Mike is correct -- the integer random number
> gen from the math library isn't all that good and is causing the
> slowdown.  And thanks to Terry for math lib suggestions.  You folks
> are great.

Thanks, your're welcome.

> I got a bunch of emails

Ignore them.  Public posts should usually be reponded to publically -- or
not at all.  Dropping negative comments in your mailbox is nasty.  Helpful
comments should be public for the benefit of everyone.  I'm glad Michael
responed publicly and reminded me that some problems, like this one, have a
better list initializer than the standard default None  (so much for
writing at 2 AM).

> saying that one shouldn't benchmark languages
> this way, or do so without knowing the language really well, or that
> my code wasn't pythonish enough.

There are occasional trolls who do a dippy 'benchmark', find Python
lacking, and then post something to the effect that Python is 'bad'.  You
were benchmarking your ability to use three languages.  When you found you
ability with Python inadequate, you asked for help and got at least three
good responses.

>  You folks need to wake up and smell  the compilers (or interpreters).

I presume 'you folks' refers to the private emailers ;-)

>  The whole point of a tool such as a
> compiler or interpreter is to take reasonable code (and in this case,
> my algorithm is certainly that -- the fault wasn't in my code but in a
> python function) and generate reasonable program speeds.

You are leaving out programmer speed, which is a large part of overall
problem solution cost.  Python is used by people who value their own time
*and* who find programming in Python to be faster than in other languages,
once a reasonable proficiency is obtained.  Some whizzes in other languages
never find the latter to be true, even after a fair trial, and so they
properly stick with their other languages.

The quality of implementation of various functions in various modules
varies.  Random.randint() is known to be slowish.  I presume it could be
made faster, but that is apparently not an itch of any of the current
contributors.  If you look at the code and see how, I presume a patch would
be welcome, but you might ask first on the development list about
undocumented rationales for the current implementation.

> Sure, experts should be able to fiddle and get something more out of it,

Here I think you are over-reacting to hitting a bad spot in the road, and
perhaps forgetting what newbie C++ code can look like, and how much you
have internalized expert fiddling in the languages you know better.

> but  the whole attraction of python for me is that it looks like pseudo
code.

Ditto, as I wrote at least 7 years ago.

>  If you can't write things the way you think, then it isn't much
> help to use python.

People who use Python do so at least in part because they find it better
fits how they think than, for instance, C++.   In any case, get it right,
then make it faster if not fast enough.  For some people, Python makes 'get
it right' easier and faster.

>  It is still the case that unoptimized code in
> borland's C++ is 5x faster than python (and that's for a windows
> program w/ dialog boxes, etc. rather than a console app), and this is
> distressing,

Remembering when CPU time cost 50-100 times as much as programmer time, I
once did too.  If you focus on total clock time from start to finish, and
on long term maintainability, you might find it less distressing ;-)  If
you use use Numerical Python, which wraps expert-written Linpack and FFT
routines, among others, or Psyco (if you can -- it is CPU specific still),
you migh find 5x less true.

> but I'll keep trying w/ python.  Python is beautiful...

Be careful, or it might grow on you.

Terry J. Reedy