From: Nat Pryce <nat.pryce@...13media.com>
Date: 2002-11-22T04:09:50+09:00
Subject: Re: Ruby is too slow

On Thu, 2002-11-21 at 18:56, MetalOne wrote:
> I also recognize that Ruby is interpreted.  However, I did not expect
> the
> factor of 200 difference.  The interpreter only needs to parse the
> loop
> once, it should then have byte code to execute for each iteration.  Of
> course,
> it must translate the byte code to machine code, for execution.  I
> would have expected some constant overhead for this translation on the
> order of 2 or 3 times.  This is a very tight loop though and every
> extra op makes a significant difference.
> 
> I knew Ruby was not up for my current task.  That is why it is being
> written in C++.  I was just curious at close it could come.  I was
> really blown away, by exactly how inadequate it is at such things.

Certainly Ruby is not designed for this particular application, but also
you used a particular feature of Ruby that would have a particularly bad
effect on performance (blocks) in a performance critical loop.  

Your C++ code was implemented using direct pointer dereferences.  If you
had instead written your code to construct non-trivial intermediate
objects representing each pixel, the inner loop would have to call the
constructor and destructor for those classes thousands of times,
resulting in poor performance.  That would not mean that C++ is slow,
just that that example of C++ code is slow.

So, yes Ruby is slow compared to C++ (it is interpreted after all), but
it is also like any other language in that you have to be careful how
you use the features of the language if performance is important.

Cheers,
	Nat.
-- 
Nat Pryce <nat.pryce@b13media.com>
B13media