Python advocacy in scientific computation
Terry Reedy
tjreedy at udel.edu
Mon Mar 6 15:57:01 EST 2006
"Magnus Lycka" <lycka at carmen.se> wrote in message
news:duh1b9$fvq$1 at wake.carmen.se...
> It seems the Python attitude to performance has largely been:
> Let Python take care of development speed, and let Moore's law
> and the hardware manufacturers take care of execution speed.
I think this is pretty fair, and yet .... the core Python interpreter has
perhaps doubled in speed (hardware held constant) since some years ago.
And new builtins like enumerate speed up code that needs to enumerate
sequence items (which is not uncommon). And class sets.Set is rewritten in
C as builtin type set primarily for speed.
It is certainly true that Guido regards continued correct performance of
the interperter to be more important that greater speed. Ditto for Python
programs.
> it seems now, increases in processing speed the coming years
> will largely be through parallell thread. If Python can't utilize
> that well, we have a real problem.
I believe it is Guido's current view, perhaps Google's collective view, and
a general *nix view that such increases can just as well come thru parallel
processes. I believe one can run separate Python processes on separate
cores just as well as one can run separate processes on separate chips or
separate machines. Your view has also been presented and discussed on the
pydev list. (But I am not one for thread versus process debate.)
> At
> least if writing threaded applications becomes less error prone
> in competing languages, this might well be the weak point of Python
> in the future.
Queue.Queue was added to help people write correct threaded programs.
> I hope to see some clever solution to this from the Python developers.
A Python developer is one who helps develop Python. Threading improvements
will have to come from those who want it enough to contribute to the
effort. (There have been some already.)
Terry Jan Reedy
More information about the Python-list
mailing list