python simply not scaleable enough for google?
Alf P. Steinbach
alfps at start.no
Sat Nov 14 10:17:15 CET 2009
> On 12 Nov, 18:32, "Alf P. Steinbach" <al... at start.no> wrote:
>> Hm, this seems religious.
>> Of course Python is slow: if you want speed, pay for it by complexity.
> Not really. The speed problems of Python can to a large extent be
> attributed to a sub-optimal VM.
> Perl tends to be much faster than Python.
> Certain Common Lisp and Scheme implementations can often perform
> comparable to C++.
> Java's Hotspot JIT comes from StrongTalk, a fast version of SmallTalk.
> It's not the static typing that makes Java run fast. It is a JIT
> originally developed for a dynamic language. Without Hotspot, Java can
> be just as bad as Python.
> Even more remarkable: Lua with LuaJIT performs about ~80% of GCC on
> Debian benchmarks. Question: Why is Lua so fast and Python so slow?
> Here we have two very similar dynamic scripting languages. One beats
> JIT-compiled Java and almost competes with C. The other is the slowest
> there is. Why? Lot of it has to do with the simple fact that Python'
> VM is stack-based whereas Lua's VM is register based. Stack-based VM's
> are bad for branch prediction and work against the modern CPUs. Python
> has reference counting which is bad for cache. Lua has a tracing GC.
> But these are all implementation details totally orthogonal to the
> languages. Python on a better VM (LuaJIT, Parrot, LLVM, several
> Sure, Google can brag about Go running at 80% of C speed, after
> introducing static typing. But LuaJIT does the same without any typing
> at all.
Good points and good facts.
And you dispensed with the word-splitting terminology discussion, writing just
"The other [language] is the slowest". Currently. He he. :-)
And it is, as you imply, totally in the in-practice domain.
More information about the Python-list