New Python User Question about Python.

[Chris Barker]

Paul Rubin wrote:

> Well, yes, applications for which Python is too slow don't get written
> in Python.  But if Python were faster, it would be useable for more
> applications, always a good thing from a Python advocacy perspective,
> I would have thought.

Absolutely!!!!

> > and there is little interest in improving its speed compared to
> > improvements in other areas.
> 
> There seems to be considerable interest in Python's speed in this
> newsgroup, I've been happy to find :)

I think there is a disconnect between improvements that the user
community (and potential user community) wants to see, and the
improvements that the Python developers themselves want to see. Being an
open source project, what gets done is what the developers what to get
done. Apparently, a major effort to optimise for speed is not on the top
of the developers list, while I suspect it is higher on the list of
users, and maybe even higher on the lists of potential users.

This is not a criticism, it is simply a fact. If someone were to create
a blazingly fast Python compiler, I'd bet they'd find a good market, but
in the meantime, open source projects produce excellent software that is
geared towards the people capable of writing that software, hence
excellent compilers and operating systems, ans far less software that is
considered "usable" by the novice.

>    a = 4.0 * b     # NumPy scalar * array multiplication
> 
> took 0.31 seconds, and just for fun I coded a simple loop in C and it
> took 0.6 seconds to run 1 million times.  So C was 300 times faster
> than a map call in Python and 50 times faster than Numerical Python.

50 times faster than Numeric??? this makes little sense (at least for
large arrays) I'd like to see the code, I suspect you were doing
something different in the C code.

> In the long run I hope there will be Python compilers and high
> performance applications being written in Python, like there currently
> are for Scheme or Lisp.

That would be a wonderful future !!
 
Peter Hansen wrote:
> > Most cases where you want big performance improvements are situations
> > where a particular small set of operations is taking up most of the
> > time. If those operations are coded as a C extension, then you don't
> > need to rewrite the other stuff that is already debugged and working,
> > and you get all the benefits of staying in the Python environment.
> 
> Exactly *why* there is relatively little interest in improving
> the speed of raw Python.  We all realize a more effective way
> to gain speed improvements is to profile and then recode as
> a C extension if (and only if) absolutely necessary.

I think this explains the disconnect I see between user's and
developer's (of Python) interest in speed optimization: A person
qualified to work on the Python interpreter can whip up a quick C
extension to speed up the bottleneck. A user like myself who is a C
novice, needs to put a whole lot of time into that same C extension. If
I could compile some Python (perhaps with a few static type declarations
or something) I'd be a whole lot more productive!! Come to think of it,
I am working on a project now with a couple of experienced C/C++
programmers. I have them writing most of the C extensions that we
require,a nd it takes them at least 5-10 times as long to write the C as
it takes me to write similar Python (it takes me 20 times as long!). We
would all benifit A LOT if that were not neccesary. If we didn't have
Numeric, we couldn't do this project in Python at all.

Note that unlike many posters, I LOVE the dynamic nature of Python, I
would not want to give that up, after all, that is why I use it. What I
wouldn't mind is if I could write just a few functions in Python that
were not so dynamic, and compile those to fast native code. 

I had high hopes for the Py2C project, it seems like it had a LOT of
potential for allowing this, but it seems to be stalled out :-(

In short: yes, speed matters, and Python could be a far more general
purpose language than it is if the speed issue were addressed as
succesfully as it has been for LISP.

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------