python simply not scaleable enough for google?
tjreedy at udel.edu
Wed Nov 18 00:31:25 CET 2009
David Cournapeau wrote:
> On Tue, Nov 17, 2009 at 10:48 PM, Aaron Watters <aaron.watters at gmail.com> wrote:
>>> I don't think Python and Go address the same set of programmer
>>> desires. For example, Go has a static type system. Some programmers
>>> find static type systems to be useless or undesirable. Others find
>>> them extremely helpful and want to use them them. If you're a
>>> programmer who wants a static type system, you'll probably prefer Go
>>> to Python, and vice versa. That has nothing to do with implementation
>>> speed or development expenditures. If Google spent a million dollars
>>> adding static types to Python, it wouldn't be Python any more.
>> ... and I still have an issue with the whole "Python is slow"
>> meme. The reason NASA doesn't build a faster Python is because
>> Python *when augmented with FORTRAN libraries that have been
>> tested and optimized for decades and are worth billions of dollars
>> and don't need to be rewritten* is very fast.
> It is a bit odd to dismiss "python is slow" by saying that you can
> extend it with fortran.
I find it a bit odd that people are so resistant to evaluating Python as
it was designed to be. As Guido designed the language, he designed the
implementation to be open and easily extended by assembler, Fortran, and
C. No one carps about the fact the dictionary key lookup, say, is writen
in (optimized) C rather than pretty Python. Why should Basic Linear
Algebra Subroutines (BLAS) be any different?
> One of the most significant point of python
> IMO is its readability, even for people not familiar with it, and
> that's important when doing scientific work.
It is readable by humans because it was designed for that purpose.
> Relying on a lot of compiled libraries goes against it.
On the contrary, Python could be optimized for human readability because
it was expected that heavy computation would be delegated to other code.
There is no need for scientists to read the optimized code in BLAS,
LINPACK, and FFTPACK, in assembler, Fortran, and/or C, which are
incorporated in Numpy.
It is unfortunate that there is not yet a 3.1 version of Numpy. That is
what 3.1 most needs to run faster, as fast as intended.
> I think that python with its scientific extensions is a fantastic
> tool, but I would certainly not mind if it were ten times faster.
Python today is at least 100x as fast as 1.4 (my first version) was in
its time. Which is to say, Python today is as fast as C was then. The
problem for the future is the switch to multiple cores for further speedups.
Terry Jan Reedy
More information about the Python-list