The future of Python immutability
steven at REMOVE.THIS.cybersource.com.au
Wed Sep 9 00:44:17 CEST 2009
On Tue, 08 Sep 2009 11:23:05 -0700, Daniel Fetchinson wrote:
>> How does Matlab speed compare to Python in general? Ruby, for example,
>> is an order of magnitude slower than Python (at least it was last time
>> I looked)
> For what operations? Under what circumstances? I'm just being pedantic
> because you mentioned comparing bananas and pears ......
In general, Ruby was significantly slower than Python "most of the time",
although my recollection was wrong about it being an order of magnitude
difference -- it was more like a factor of 3-6 depending on the specific
benchmark being tested. This was for Ruby 1.8, Ruby 1.9 included some
significant speedups, including tail-optimization which makes it about
three times as fast as Python 2.5 for tail-recursive functions.
Of course there's a lot of hand-waving in the above. Language
implementations vary in their performance for specific pieces of code --
it's invalid to conclude that every single Ruby script will be exactly 3
times faster than every single Python script. But one can argue that Ruby
1.8 was, in general, at least three times slower than Python 2.5
comparing equivalent pieces of code.
There's nothing controversial or strange over the claim that a well-
written (but not heavily optimized) C program will be much faster than
the equivalent Python program, which in turn will be faster than the
equivalent PHP program. Nobody is surprised to learn that Numpy's C
implementation of some function will almost certainly out-perform the
same function written in pure Python. It's easy to oversell the idea that
"language X is faster than language Y", but that's not what I'm doing.
I'm asking, all else being equal, how does the speed of Matlab compare to
the speed of Numpy?
>>, not because of immutable arrays, but just because of the speed
>> of the language.
> Ummmm, what is 'speed of a language'? I thought ruby or python or
> anything else as a language is separate from their implementations.
> Implementations might have 'speed' but languages don't. Aren't you
> comparing bananas and pears again?
Go point -- of course you're right, and I was sloppy. I meant "the speed
of the specific implementation".
More information about the Python-list