[Edu-sig] Re: Edu-sig digest, Vol 1 #316 - 6 msgs

[Brent Burley]

Roman Suzi said:
> On Sun, 3 Jun 2001, L. Humbert wrote:
> >http://www.bagley.org/~doug/shootout/
> 
> ...
> Seriously, Python doesn't shine according to
> this comparison :-(
> I expected it to be ahead of Java in most categories,
> expecially IO-related ones...

I'm not sure this is the right forum for this discussion, but lest any
educators shy away from Python because of this, I'm offering this
rebuttal.

First, I don't think these benchmarks reflect real-world usage.  Second,
I don't think they have all been optimized equally.  Third, some of
languages bend the definition of the test or cheat using knowledge of
the nature of the test.  That said, I think the benchmarks are
interesting and do a reasonable job of reflecting the relative overall
performance of the languages involved (within a factor of 2 or so); it's
just hard to do an accurate benchmark.  But, my biggest criticism of the
benchmark is that runtime speed isn't always (or even very often) the
most important quality of a language.

While I do think performance is the weakest aspect of Python, it's more
than fast enough (especially on today's PC's) for most tasks.  And if
you're doing something performance critical you're most likely going to
use C or C++.  The beauty of Python is that is mixes very well with
C/C++.  I working on a very large project where I'm trying to do
everything I can get away with in Python.  The Python parts are
developed more quickly, are easier to modify, and tend to be more
robust.  I rewrite modules (or portions of them) in C++ when performance
becomes an issue.

I think the performance of Python could be quite a bit better, and I
think there has been more effort to focus on improving Python's
performance recently.  But the dynamic nature of Python puts a limit on
how much can be achieved.  I think the addition of optional type
declarations on variables would help a lot with computations.  And the
cost of name lookups (especially methods and members) seems an obvious
target for a big payback.

I looked at one of the benchmarks, strcat, as an example.  The goal is
to build a large string by incremental concatenation.  Unfortunately
(for this benchmark) because of the immutable nature of Python strings,
Python doesn't support direct concatenation.  The Python implementation
instead builds a list of strings and then calls string.join on the
list.  This seems like cheating to me, especially since it just puts the
same string in the list n times.  But even so, it is not the best
implementation.  I tried preallocating the list rather than using
append() and cut the time in half.  I then tried using (string * n) to
replicate the string and cut the time by an additional 95%!  This is
even more cheating, but it achieves the correct program result.  My
point is that the benchmarks are too oriented towards implementing a
very small program fragment in a very particular way.

If it were possible to benchmark programmer productivity objectively, I
think Python would rate very high.  I've been a professional programmer
for roughly 13 years and I've used Fortran, Pascal, C, Lisp, Assembly,
Perl, C++, and Python on the job (for at least 2 years each).  I would
definately say that Python gives me the most productivity by a
significant margin.

	Brent Burley