Some Ruby (the programming language) blogger has tried to implement the Edit-Distance algorithm in three different ways in both Python and in Ruby. His conclusion is more steered towards the difference between the algorithms and not so much the language. I guess that's fair because the implementation might be done better in Python than it was in Ruby. But, please notice that this is a Ruby coder and yet his Python implementations are always faster.
A quick glance tells me that the Python programs run about 3 times as fast as the Ruby ones. See the benchmarks
Comments
Post your own commentThis is due to implementation not language. Ruby is using AST evaluation, while Python uses bytecode compiling+interpretation. Ruby 2.0 will probably change this. From a language implementors POV they are fairly similar and should be able offer similar performance.
This is true, I am hoping that Ruby 2.0 (rite) will close the performance gap. But when will it actually happen? We have been hearing about rite for years now. The way things are going hell will freeze over or even (gasp) perl 6 will be released before 2.0 is ready.
He comes up with a rather odd conclusion -- that the algorithm matters most -- when it seems that the fastest Ruby algorithm is about twice as slow as the slowest Python algorithm.
It is true that Ruby will probably have a VM in 2.0 -- and probably a faster VM than CPython's unadorned VM -- but Python already has an optimizer that could probably do great on this algorith (psyco), and a working (but still young) system that could probably compile these fairly straight-forward algorithms into fast C (PyPy).
in other words... python rocks?
However, I think rb is as fast as it needs to be. The same for python. It's rarely computation speed that is the bottleneck and when it does become a bottleneck you take out psyco or gcc.
Python has many good things going for it, but I don't think performance comparisons are something the community should be using as selling points. When you expand your comparisons beyond Ruby, you start to find language implementations where the difference isn't quite that favourable...
Python does not stand a chance if you pitch it against C/C++, but as long as you stick to the same kind of languages (i e interpreted, dynamically typed), Python is probably one of the fastest languages around.
For example, does it almost consistently perform better than Perl, TCL and Ruby in all the algorithmic tests in the Computer Language Shootout (http://dada.perl.it/shootout/) and if you pair it together with Psyco you get very close to the speed of a compiled language.
You are right when you say that the performance is not Python's main selling point, but the execution speed is more than often for sufficent for most applications, and for the rest you have a number of options:
* Use Psyco
* Use Pyrex to translate part of you Python code to C
* Write an extension module in C/C++ (e g with the help of SWIG, BOOST)
* Wait for PyPy to be ready... :)
A good thing about Python is the vast amount of optimisation tools like you list Jan. Does perl and ruby have this too?
Python scripts full of complex regular expressions, are they really much faster rewritten in C/C++? For that kind of stuff, isn't python just a simplified API of a big fat C program?
I'm not that familiar with the tools available for Perl and Ruby, but apart from the JIT (Psyco, which I think is quite unique), I wouldn't be suprised if similar tools existed for those languages, and apart from that, writing an extension module is of course always an option.
Python scripts are often constituted by a number of calls to an optimized C library, where the Python code only works as the "glue" needed to express the program logic. However, this buys us expressivity without having to pay the price of maintaining the complex low level code. John K. Ousterhout (who created TCL) has written a paper about this http://home.pacbell.net/ouster/scripting.html.
This probably the main reason that the Very High Level Languages (VHLL's) are performing as good as they are.
The same thing also apply to Java. Some of the most important classes (String is an example), is almost totally implemented with native code in C, and there is not much perfomance to be gained by making the virtual machine perform better when it comes to string handling.
"The Great Win32 Computer Language Shootout" has not been updated in the last 2 years.
"The Computer Language Shootout" is active, see
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=python&sort=fullcpu
To contribute programs see the FAQ
http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute
So, python occasionally uses more memory but clearly much faster than ruby. Thanks for the link Isaac.
I don't think that a two to three times speed difference matters that much, it matters a lot more that the ruby code is much more beautifull in my eyes. But remember that I did this to learn something about python, not to smash one of the languages. As the "pragmatic programmers" put it, one should learn a new language each year, and it is always possible to learn something from each language.
On a sidenote, if this edit-distance code would really be used, I'd recode it in c to which ruby has a beautifull binding. That would be as fast as it gets. But on the other hand, there are edit-distance algorithms which are faster and use less memory, so first I'd improve on this line. Also note that both implementations do not use much of what makes ruby and python worthwile, there is no metaprogramming or other nice techniques used. Maybe I'll reimplement the algorithms using a memoization library to abstract away more of the algorithms.
regards,
Brian
Brian:
Both
# Missing the [i,j] operator
and
# Missing the [i,j]=v operator
is false, they can be implemented with __getitem__ and __setitem__.
Joins of lists are usually not done with an imported string module but with "sep".join(list) wich makes some sense if you think of it. "With this string join this list" instead of as in Ruby "with this list join with this string".
if a[i] == b[j]:
. cij = 0
else:
. cij = 1
Could instead be written as int(not a[i] == b[j])
Sebastian:
Thank you for the clarifications. Would you mind showing how to do the __getitem__ an __setitem__ thingie. I remember I tried it but could not get it to work with multiple arguments.
Regarding join, thank you I learned something new. It seems it's a matter of perspective. Though I'd express array.join(string) as "ask the array to join itself using string as a seperator" ;-)
The int(not a[i] == b[j]) though is something I'll never allow in my programs. I like to distinguish between false, true and numbers and the above is certainly golfish.
regards,
Brian
__getitem__ and __setitem__ get their arguments as a tuple. l[2,3] will call l.__getitem__((2,3))
What's wrong with converting a bool to int if it makes the code cleaner and easier to read?
Also, the to_s method should probably be replaced with __str__ instead, wich will be called by str(object). The reason of the usage of these functions to help functional programming, for instance: map(str, someCollection) wich i Ruby would be: someCollection.map{ |obj| obj.to_s }
Thank you for the hints. I'll try it later today.
Regarding the bool to int conversion it is my opinion that a boolean is a type with a domain of {false, true} and I do not have an implicit mapping from {false, true} to int. It is as sensible for false to map to -1 as it is to map to 0. The same holds for true. So I do not want to rely on this arbitrary mapping wich seems more like a coincidence than a resonable idea to me.
_Join the equal rights for zero movement_
Why should 0 be false even if it is a completely normal number?
regards,
Brian
Ah, I found a way to solve this in python. I can define a hash indexed by true and false. e.g.
{true: 0, false: 1}[a[i] == b[j]]
does the same as
a[i] == b[j] ? 0 : 1
Nice, that's a trick I haven't used before. I like it. :)
I agree that learning a new language is a good thing, but Ruby is actually one of the few languages around, where I just can't motivate myself to put some effort behind it.
From my perspective (troll alert), Ruby looks a lot like Python with the exception of explicit blocks, and that alone is not going to make any single Python developer switch. Also being part of a community where some of the conversations/documentation is done in Japanese (e.g http://jp.rubyist.net/magazine/?0008), doesn't really sound that appealing to me.
Simply put: Ruby is too similar to Python for me to care. Given the immaturity (lack of libraries, three times slower, No JIT, etc), the choice for people like me, already knowing Python, is actually quite easy.
I don't think anybody would want to make you switch. Everybody should use the right tool for the job. And for joy in programming for me the right tool is ruby for you it might be python.
The point I disagree with you is the problems that the existence of a japanese community brings. I hope that python also has some users whoose mother tongue is not english, and ruby has a really nice english speaking community and a helpfull mailing list/newsgroup comp.lang.ruby where matz (the language creator) participates.
regards,
Brian
A good thing about Ruby is that it keeps the python-dev guys on their toes thus producing a better Python.
A good thing about Python is that it keeps the ruby-dev guys on their toes thus producing a better Ruby.
I think few people come to a crossroad where they chose either Python or Ruby. Most people will see Java, C, Perl at the crossroad and once they've gone down the Ruby one they'll ignore the sidelining python one because there's little additional benefit for changing your mind.
Diversity is a good thing and everyone should use the tool they best think suits their problem. I can find many good reasons to use C/C++, or even Prolog or Lisp for specific problem domains. However, I really cannot see the light when it comes to Ruby. There is simply to little innovation brought into the game for me to care, but I'm the first to admit that I'm heavily biased, having used Python for more than ten years now.
Talking about the Japanes issue, I think this says it all:
"Does anyone else continually wish they could read japanese and in turn read Matzs blog?"
A Ruby user complaining on: http://redhanded.hobix.com/cult/noteToGuidoOrientalNotOccidental.html.
Sorry, I am surely somehow responsible for this but I do not aim at a ruby is better than python because of ... discussion. I like it, c.l.r and redhanded gives me enough to read about ruby and I like to do gg=G in my vim editor, but I really don't want to evangelicalize anyone.
happy pythoning,
brian
(troll alert noticed ;-)
You'd read the Pickaxe book to know it's somewhat inspired by Python among other noteworty languages too but it's rather opposite to it.
I'll not try to sell you proper object model (including Exceptions being not that weird clunks of TODOs for some distant future as in python), or the elegance instead of __ugly_stuff__, or anything else. It's acquired, not sold. ;)
(note that I've actually tried to like Python several years ago in one project but it was way too ugly and inconsistent and mentoring deeply irrelevant syntax on me to stand it)
PS: Peter Bengtsson expressed the situation quite clearly ;-)
Speed is not everything.
Thank you.
Definitely true if you get other benefits in trade of speed like you do with both Ruby and Python.
It may be that speed is everything!
It may be that speed is everything and not determined by language implementation.
It depends what you are trying to do.
oh another topic ruby/python that turn into useless flamewar
cuz ruby is the small guy and python is the big boy
come on, it doesn't matter, they're similar enough that you should use the one you are comfortable with.
and if you really need performance maybe you'd still rather go python, or C ;p