From: Chad Perrin Date: 2007-09-24T23:38:37+09:00 Subject: Re: This is why Ruby 1.8.6 can never be made to run anywhere near as fast as Python 2.5.1 Some others have addressed many of your points admirably. For the most part, I didn't really see much point in responding to what you had to say. On the other hand, a couple of items just bothered me so much I can't really help myself. On Mon, Sep 24, 2007 at 11:55:05AM +0900, Ruby Maniac wrote: > > Given the best Ruby is capable of doing versus the best Python is > capable of doing Ruby ends up being more than 20x slower than Python > and I think I know why. > > It is just not possible to make Ruby 1.8.6 execute any faster than the > Ruby interpreter is capable of executing the code due to the lack of a > byte-code driven VM. Maybe someday YARV will make Ruby code run 2x > faster than Ruby 1.8.6 but that day has not arrived yet and may never > arrived. > > Even if YARV proves to be 2x faster than Ruby 1.8.6 the resulting Ruby > code will still be 10x slower than the fastest Python code. I guess you haven't been watching the recent thread that revealed how much of a performance boost you can get moving from 1.8.6 to 1.9 (among other means of reducing execution time). > > The bottom line is that Python can be made to run as fast as machine > code but Ruby cannot. Sure it can. A language does not, in and of itself, dictate the form of the implementation. There could conceivably one day be an optimizing binary compiler implementated for Ruby while Python might not progress much beyond where it is now (or vice-versa). You'd suddenly find that Python does *not* actually execute as fast as "machine code" (meaning binary executables, as opposed to VM bytecode). The fact that Ruby uses an interpreter right now doesn't mean that things won't change in the future. On the other hand, for many types of development projects, programmer time is a lot more valuable than CPU time. In such circumstances, Ruby is one of the best choices around for development language. > > Python is useful for problems that require fast runtimes such as 3D > modelling or video game programming. > > Ruby would not be fast enough for the kinds of problems where people > are using Python. Not so much -- not much more so than Ruby, at any rate. People write "serious" games in C++ for the most part, these days. Python doesn't even begin to compare in that realm. In cases where speed matters enough that Ruby isn't even an option, people are generally avoiding Python, too. Only in cases where people like to *think* speed matters, but it doesn't really, do people choose something like Python over something like Ruby on performance grounds. > > When I write code I want to know I am using tools that give me the > best performance for the effort that I can possibly get as opposed to > tools that guarantee no matter how hard I work performance will always > be lacking. You might want to move from Python to Perl, then. Maybe you should then move from Perl to C++. Of course, then perhaps you should consider moving from C++ to Objective Caml. At that point, you might consider moving on to C. Once you get to C, you might consider moving on up to assembly language. While you're playing around in assembly language, you could even choose your architecture (and thus your specific flavor of assembly language) based on the CPU instruction set. Let me know when you get to the point that you're writing the equivalent of shell scripts in assembly on the architecture with the most efficient CPU instruction set. At that point, I'll believe what you say about putting all your eggs in the performance basket. > > When people choose to make their choices of languages a religious > issue they can become rather short-sighted in how they choose to > resolve programming problems. Yes, you can certainly do that when you religiously attach yourself to single-issue arguments for one language over another. > > I prefer to be agnostic about programming languages. I choose those > that perform the best and I ignore the rest. These are contradictory statements. I'm sure pretty much everyone here can see the faults in your arguments for what they are. As such, you're not really doing a lot of damage to the reputation of Ruby -- and any attemps to chalk all this up to an attempt to get Ruby core developers to change their focus to performance are self-evident nonsense, considering I'm sure they know far better than you (and me) the key issues they face. On the other hand, you're positioning yourself as a representative of Python on a Ruby list. I'm not a fan of Python. I don't personally like it. On the other hand, I can step back and (somewhat) objectively recognize Python's advantages as a language. It really is a great language in purely technical terms, as are Ruby, Perl, Objective Caml, and a host of other languages, regardless of whether it's a great language *for me*. If you're doing any damage to any language community, however, it's to the Python community, by giving people one more data point in their statistical comparisons of the attitudes of Pythonistas. That's not very fair to the Python community. You'd be doing us a favor if you stopped contributing to the Noise:Signal ratio, but you'd be doing Python's community a bigger favor by ceasing to pretend to advocate for Python. I really only comment on this in hopes that it may forestall any knee-jerk reactions to you that may lead to others judging Python more harshly because of this one self-appointed representative. In other words, I may be addressing you, but you're not my audience. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] Kent Beck: "I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby."