How to speed up ruby and make it as fast as possible

ruby-talk
1

You are mistaken. Current, stable Perl and Python releases typically
execute programs much faster than Ruby. I suspected such rationalizing
and hostile replies in my initial post.

Jamal

···

-----Original Message-----
From: Kevin Clark [mailto:kevin.clark@gmail.com]
Sent: Friday, July 14, 2006 2:40 PM
To: ruby-talk ML
Subject: Re: How to speed up ruby and make it as fast as possible

Jamal,
Stop being a troll.

Ruby is comparable in speed to other interpreted languages. If you'd
like to speed up your code profiling your code and cleaning up
algorithmic bottlenecks is the simplest way. After that, optimizing in
C is the way to go. You don't have to do it this way, but it is one of
the few answers to the problem and is a valid response to the
question.

--
Kevin Clark
http://glu.ttono.us

2

You are mistaken. Current, stable Perl and Python releases typically
execute programs much faster than Ruby. I suspected such rationalizing
and hostile replies in my initial post.

I'm jumping into the middle of the thread, but, I do believe
you're missing a few important points.

1. Most of us are already aware of ruby's speed.

   1a. Many of us are able to write entire applications
       in ruby today, and find that it's "fast enough"
       for these applications.

         - For example: I have written several internet
           and web applications in ruby, and for my needs, ruby was plenty fast for these
           applications.

   1b. Some of us are writing applications for which
       ruby is NOT fast enough, by a couple orders of
       magnitude.
                - For example: A 3D video game, with polygon
           rendering, collision detection, physics,
           monster AI, etc.
           I am developing a 3D application, and I'm
           writing as much code as I can in ruby.
           But it doesn't matter if someone comes along
           and says "ruby needs to be faster".
           Ruby will NEVER, in any foreseeable future that
           matters to the software I'm writing, be fast
           enough to handle real-time rendering, physics,
           and collision detection for a complex 3D
           world.
           This is an important point I think you're not
           realizing: It's not a matter that people don't
           "want" ruby to be faster. There is just NO
           KNOWN technical way to make ruby fast enough
           for some applications.
           Therefore, for my 3D application, I write as much
           as I can in ruby, and code the rest in C.
           Saying "ruby needs to be faster because I don't
           want to learn C" is just nonsense for some kinds of applications. For these applications,
           recommending C is not "rationalizing away ruby's
           slowness" and it's not intended as a "hostile
           response." It's just true, because there's NO KNOWN way to make ruby fast enough, no matter
           how much you want it to be.

2. Probably anyone here will agree with the idea that
   it would be *nice* for ruby to be faster, provided
   we don't have to change the language to get the speed.

Did I leave anything out?

As I mentioned, ruby is _already_ fast enough for some
applications, and _will never be_ fast enough for others.

Regards,

Bill

···

From: "Jamal Mazrui" <Jamal.Mazrui@fcc.gov>

3

There are certain sore spots in language discussions which tend to get
feathers ruffled. Seeing this thread has garnered so many replies in
such short time uncovers a sore spot in Ruby language discussion. Ruby
tends to be slower than other similar interpreted scripting languages.
Although some folks won't admit it as a broad generalization this
assertion tends to be stereotypically correct.

Every language has its sore spot. For Python try bringing up
significant whitepace or passing the understood 'self' around each and
every method. For Java try bringing up the truth of 'write once run
everyone' or mixing primitives in with objects for a supposedly OO
language. For Perl try bringing up cryptic lack of readibility and
"bolted on" version updates. For PHP try bringing up secure coding
practices. And so on...

Bill Kelly wrote:

···

From: "Jamal Mazrui" <Jamal.Mazrui@fcc.gov>
>
> You are mistaken. Current, stable Perl and Python releases typically
> execute programs much faster than Ruby. I suspected such rationalizing
> and hostile replies in my initial post.

I'm jumping into the middle of the thread, but, I do believe
you're missing a few important points.

1. Most of us are already aware of ruby's speed.

   1a. Many of us are able to write entire applications
       in ruby today, and find that it's "fast enough"
       for these applications.

         - For example: I have written several internet
           and web applications in ruby, and for my
           needs, ruby was plenty fast for these
           applications.

   1b. Some of us are writing applications for which
       ruby is NOT fast enough, by a couple orders of
       magnitude.

         - For example: A 3D video game, with polygon
           rendering, collision detection, physics,
           monster AI, etc.
           I am developing a 3D application, and I'm
           writing as much code as I can in ruby.
           But it doesn't matter if someone comes along
           and says "ruby needs to be faster".
           Ruby will NEVER, in any foreseeable future that
           matters to the software I'm writing, be fast
           enough to handle real-time rendering, physics,
           and collision detection for a complex 3D
           world.
           This is an important point I think you're not
           realizing: It's not a matter that people don't
           "want" ruby to be faster. There is just NO
           KNOWN technical way to make ruby fast enough
           for some applications.
           Therefore, for my 3D application, I write as much
           as I can in ruby, and code the rest in C.
           Saying "ruby needs to be faster because I don't
           want to learn C" is just nonsense for some
           kinds of applications. For these applications,
           recommending C is not "rationalizing away ruby's
           slowness" and it's not intended as a "hostile
           response." It's just true, because there's
           NO KNOWN way to make ruby fast enough, no matter
           how much you want it to be.

2. Probably anyone here will agree with the idea that
   it would be *nice* for ruby to be faster, provided
   we don't have to change the language to get the speed.

Did I leave anything out?

As I mentioned, ruby is _already_ fast enough for some
applications, and _will never be_ fast enough for others.

Regards,

Bill

4

Bill Kelly wrote:

Did I leave anything out?

Just because you asked: yes.

As I mentioned, ruby is _already_ fast enough for some
applications, and _will never be_ fast enough for others.

There would be even more applications ruby would be fast
enough for if ruby would just be a little bit faster.

I don't get the problem with someone who wishes ruby to
be even better (yes, that means faster this time, performance
is one quality of software, along with a lot of others)
than it already is.

Regards,

Bill

cheers

Simon

5

Bill Kelly wrote:

As I mentioned, ruby is _already_ fast enough for some
applications, and _will never be_ fast enough for others.

There would be even more applications ruby would be fast
enough for if ruby would just be a little bit faster.

That's like saying if the moon was closer to the earth, the tides would be higher... no shit.

I don't get the problem with someone who wishes ruby to
be even better (yes, that means faster this time, performance
is one quality of software, along with a lot of others)
than it already is.

Here's a novel idea, and please forgive the attitude I must be coming across with, it's not my intent: Instead of bitching about these things endlessly on the mailing list, how about those who find it terribly important that it [ruby] be fast enough for them, work on making it fast enough for them. Rest assured, nobody else is going to do it for you unless it serves them as well or they're being paid.

···

On 14-Jul-06, at 4:04 PM, Simon_Kröger wrote:

Simon

--
Jeremy Tregunna
jtregunna@blurgle.ca

"One serious obstacle to the adoption of good programming languages is the notion that everything has to be sacrificed for speed. In computer languages as in life, speed kills." -- Mike Vanier

6

Bill Kelly wrote:

Did I leave anything out?

Just because you asked: yes.

As I mentioned, ruby is _already_ fast enough for some
applications, and _will never be_ fast enough for others.

There would be even more applications ruby would be fast
enough for if ruby would just be a little bit faster.

Yes... but the reason I stated it in terms of limits,
was to show that what you're saying will always be true.

No matter how fast ruby gets, there will always be even
more applications ruby would be fast enough for if ruby
would just be a little bit faster. (Although, as
programmers, we are very very used to needing to optimize
our software to be just a little bit faster in any
language... So if software is 'almost' fast enough to
work in ruby, usually we do the same thing in ruby that
we would do in C or Java, etc... find a way to optimize
it to be 'fast enough'.)

I don't get the problem with someone who wishes ruby to
be even better (yes, that means faster this time, performance
is one quality of software, along with a lot of others)
than it already is.

I don't see a problem with wishing ruby were better or
faster, either. Believe me... I do an awful lot of
wishing that I could write a whole 3D game in ruby.
I'm wishing that most every day...

But in practical terms, there will almost certainly
always be some set of applications too demanding to
be written in 100% ruby.

So..... ?

a. Who thinks it would be nice if ruby were faster?

   (Whole room raises hands.)

b. Who can estimate, based on progress with YARV, and
   historical speed gains of Smalltalk VM's, how much
   faster ruby is likely to _ever_ get, compared to its
   current performance?

   (2x? 4x? 8x? ....?)

c. Who has anything new to add that would help the folks
   already working on making ruby faster?

Regards,

Bill

···

From: "Simon Kröger" <SimonKroeger@gmx.de>

7

Jeremy Tregunna wrote:

Instead of bitching about these things

Someone asked:

"Is there a ruby configuration file that I can change to help speed
ruby up and take as much resources as it needs?"

The answer is probably: no.

But we have a holy war here.

I don't get it.

cheers

Simon

8

Bill Kelly wrote:

There would be even more applications ruby would be fast
enough for if ruby would just be a little bit faster.

Yes... but the reason I stated it in terms of limits,
was to show that what you're saying will always be true.

Agreed.

I don't get the problem with someone who wishes ruby to
be even better (yes, that means faster this time, performance
is one quality of software, along with a lot of others)
than it already is.

I don't see a problem with wishing ruby were better or
faster, either. Believe me... I do an awful lot of
wishing that I could write a whole 3D game in ruby.
I'm wishing that most every day...

I just don't like if someone gets lapidated for saying so.

But in practical terms, there will almost certainly
always be some set of applications too demanding to
be written in 100% ruby.

True, no one was questioning that.

Let's write some code, I'm better writing ruby than doing
smalltalk (erm, well you know what i mean)

cheers

Simon

9

But we have a holy war here.

I don't get it.

It's not a holy war. It's a spectrum of facts and
wishes and theoretical limitations and human resources.

Regards,

Bill

···

From: "Simon Kröger" <SimonKroeger@gmx.de>