python simply not scaleable enough for google?

[Vincent Manis]

On 2009-11-13, at 23:20, Robert Brown wrote, quoting me:
> On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: 
> 
>>> ... Python *the language* is specified in a way that
>>> makes executing Python programs quickly very very difficult.  
> 
>> That is untrue. I have mentioned before that optional declarations integrate
>> well with dynamic languages. Apart from CL and Scheme, which I have
>> mentioned several times, you might check out Strongtalk (typed Smalltalk),
>> and Dylan, which was designed for high-performance compilation, though to my
>> knowledge no Dylan compilers ever really achieved it.
> 
> You are not making an argument, just mentioning random facts.  You claim I've
> made a false statement, then talk about optional type declarations, which
> Python doesn't have.  Then you mention Smalltalk and Dylan.  What's your
> point?  To prove me wrong you have to demonstrate that it's not very difficult
> to produce a high performance Python system, given current Python semantics.
The false statement you made is that `... Python *the language* is specified 
in a way that makes executing Python programs quickly very very difficult. 
I refuted it by citing several systems that implement languages with semantics
similar to those of Python, and do so efficiently.  

>> I've never looked at CLPython. Did it use a method cache (see Peter
>> Deutsch's paper on Smalltalk performance in the unfortunately out-of-print
>> `Smalltalk-80: Bits of History, Words of Advice'? That technique is 30 years
>> old now.
> 
> Please look at CLPython.  The complexity of some Python operations will make
> you weep.  CLPython uses Common Lisp's CLOS method dispatch in various places,
> so yes, those method lookups are definitely cached.
Ah, that does explain it. CLOS is most definitely the wrong vehicle for implementing
Python method dispatch. CLOS is focused around generic functions that themselves 
do method dispatch, and do so in a way that is different from Python's. If I were
building a Python implementation in CL, I would definitely NOT use CLOS, but 
do my own dispatch using funcall (the CL equivalent of the now-vanished Python 
function apply). 

> Method lookup is just the tip if the iceburg.  How about comparison?  Here are
> some comments from CLPython's implementation of compare.  There's a lot going
> on.  It's complex and SLOW.
Re comparison. Python 3 has cleaned comparison up a fair bit. In particular, you 
can no longer compare objects of different types using default comparisons.
However, it could well be that there are nasty little crannies of inefficiency 
there, they could be the subject of PEPs after the moratorium is over. 

>    <quoting from the CLPython code>
>   ;; The CPython logic is a bit complicated; hopefully the following
>   ;; is a correct translation.
I can see why CLPython has such troubles. The author has endeavoured to copy
CPython faithfully, using an implementation language (CLOS) that is hostile 
to Python method dispatch. 

OK, let me try this again. My assertion is that with some combination of JITting, 
reorganization of the Python runtime, and optional static declarations, Python 
can be made acceptably fast, which I define as program runtimes on the same order 
of magnitude as those of the same programs in C (Java and other languages have 
established a similar goal). I am not pushing optional declarations, as it's 
worth seeing what we can get out of JITting. If you wish to refute this assertion, 
citing behavior in CPython or another implementation is not enough. You have to 
show that the stated feature *cannot* be made to run in an acceptable time. 

For example, if method dispatch required an exponential-time algorithm, I would 
agree with you. But a hypothetical implementation that did method dispatch in 
exponential time for no reason would not be a proof, but would rather just be 
a poor implementation. 

-- v