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."