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

ruby-talk
1

Certainly, Ruby performance is not always a problem. It may not even be
a problem in most situations. The issue arises enough on the list,
however, that, combined with personal experience, I am convinced it is a
significant problem. I think Ruby has few problems compared to other
languages, but this is probably its biggest one. Quantifying it more
than that is difficult, and should not be necessary for it to be
acknowledged as a valid concern.

Since the message that began this thread asked how to speed up Ruby
programs, it was obviously a problem for that author. Also, if it was
not a problem, why would speed improvement be a major goal of YARV/Ruby
2?

Not everyone is in a position to contribute directly to the improvement
of the Ruby language/VM. They still have a stake in the community,
however, and contribute in other ways. Those who are in a position to
improve the language will probably produce more valued results if
informed about our needs as developers. Evidently, increased speed is
not important to everyone, but expressing an interest in it should be
o.k., too.

Regards,
Jamal

···

-----Original Message-----
From: khaines@enigo.com [mailto:khaines@enigo.com]
Sent: Friday, July 14, 2006 2:28 PM
To: ruby-talk ML
Subject: Re: How to speed up ruby and make it as fast as possible

You insist that this is a "problem".

But you neither qualify or quantify the problem. Why is current Ruby
performance a problem, and at what level of performance does it cease to

be a problem?

Kirk Haines

2

Jamal Mazrui wrote:

Certainly, Ruby performance is not always a problem. It may not even be
a problem in most situations. The issue arises enough on the list,
however, that, combined with personal experience, I am convinced it is a
significant problem. I think Ruby has few problems compared to other
languages, but this is probably its biggest one. Quantifying it more
than that is difficult, and should not be necessary for it to be
acknowledged as a valid concern.

Since the message that began this thread asked how to speed up Ruby
programs, it was obviously a problem for that author. Also, if it was
not a problem, why would speed improvement be a major goal of YARV/Ruby
2?

Not everyone is in a position to contribute directly to the improvement
of the Ruby language/VM. They still have a stake in the community,
however, and contribute in other ways. Those who are in a position to
improve the language will probably produce more valued results if
informed about our needs as developers. Evidently, increased speed is
not important to everyone, but expressing an interest in it should be
o.k., too.

Regards,
Jamal

+1

I don't get why Jamal is called a troll here.

I would love ruby to be faster. How fast? I don't know, as fast as possible
I guess. I would even love C to be faster, and a lot of people spend a lot
of effort to make that happen (optimizing optimizers). There is nothing wrong
with that (not for C and not for ruby).

The original Poster was asking very specific things like configurations,
resources, memory limits, priorities and got

"Write it C."

as an answer. I would consider that trolling, and jamal seems to think so too.

cheers

Simon

3

Certainly, Ruby performance is not always a problem. It may not even be
a problem in most situations. The issue arises enough on the list,
however, that, combined with personal experience, I am convinced it is a
significant problem. I think Ruby has few problems compared to other
languages, but this is probably its biggest one. Quantifying it more
than that is difficult, and should not be necessary for it to be
acknowledged as a valid concern.

Performance concerns must *always* be quantified to be addressed. If
you ask whether Ruby is slower than other languages, the answer must
always be "at doing what"? It's that simple. Now, certainly, a
well-tuned C program will (almost always) outperform a well-tuned Ruby
program. But the C program will typically be harder to maintain. Since
you've admitted that you haven't studied CS, you may have missed the
mantra: beware premature optimisation.

If you try to do something that you think will be faster without
qualification and quantification of the performance metrics, you
*will* *fail*.

Since the message that began this thread asked how to speed up Ruby
programs, it was obviously a problem for that author. Also, if it was
not a problem, why would speed improvement be a major goal of YARV/Ruby
2?

Was it? The OP never responded to "what are you trying to do" but
instead had vague statements.

Not everyone is in a position to contribute directly to the improvement
of the Ruby language/VM. They still have a stake in the community,
however, and contribute in other ways. Those who are in a position to
improve the language will probably produce more valued results if
informed about our needs as developers. Evidently, increased speed is
not important to everyone, but expressing an interest in it should be
o.k., too.

No one ever said otherwise. To argue such is to argue against a
strawman. Increased speed is desired, certainly, but to me it is not
the paramount thing.

-austin
BTW, stop top-posting.

···

On 7/14/06, Jamal Mazrui <Jamal.Mazrui@fcc.gov> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

4

Jamal Mazrui wrote:

Certainly, Ruby performance is not always a problem.

We agree on this point, completely.

Quantifying it more than that is difficult, and should not be
necessary for it to be acknowledged as a valid concern.

Translation "I'm too lazy to quantify it more than that."

Which is not our problem. IF you took the time to study
application performance, and the specific areas where Ruby's
performance is perfectly fine, you'd be able to carry on
a much better argument. As it is, you admit you don't have the
patience to do that.

I however am not so constrained. In fact, I'm a bit obsessed
with benchmarking any new language I run into. I fully
expected Ruby to be a lot slower because of statements
like yours. What I found after fairly exhaustive benchmarking,
however, was quite illuminating.

Ruby does very well against both Perl and Python in many
benchmarks. It does indeed fall behind in a few areas. But I was
both surprised and pleased to see that it keeps up very well
where it counts.

In fact, I was very surprised to find that it even beats Java(!)
in some benchmarks, most notable are math with BigNumbers
and some regular expression parsing. Both features with a
wide range of applicable problem domains.

Would it be great to have a p-code or other compiled version
of Ruby? You bet. Does that mean Ruby has performance issues
making it inappropriate for professional development? Not at
all.

I'm afraid that after 20+ years of software development, I've
learned that the time to create the program is usually
more important the the final performance of the program. This
is NOT always true. Certainly not for things like video games.
However, I have also learned that by the time you get around
to squeezing every last drop of performance from a language,
the hardware people triple the speed of the platform, and the
performance problems are suddenly less important.

Note, I'm not saying your points are invalid. I'm just saying that
you won't convince anyone here with statements like
"Quantifying it more than that is difficult," when it is actually
quite easy.

5

(sorry for my poor english)

Jamal Mazrui wrote:

Certainly, Ruby performance is not always a problem. It may not even
be
a problem in most situations.

Language performance is not a problem in many situations.

The issue arises enough on the list,
however, that, combined with personal experience, I am convinced it is
a
significant problem. I think Ruby has few problems compared to other
languages, but this is probably its biggest one.

you are 'convinced', you 'think', 'probably' ...
Many people were convinced of things which are false or at least not
true, I was too. It doesn't worth benchmarks.

Quantifying it more
than that is difficult, and should not be necessary for it to be
acknowledged as a valid concern.

Quantifying is not that difficult for some specialized use of a
language, Ruby is a general purpose language.
If you use it for scripting, say something like scanning logs, it
doesn't even worth spending 1 day benchmarking to know which of Ruby,
Perl & friends will save or lose 1 millisecond of CPU time in a year.
For desktop application, if the user have it's response in a tenth of a
second instead of 2 tenth of a second you don't save half of the time,
you just do not save nothing for obvious reasons.

Since the message that began this thread asked how to speed up Ruby
programs, it was obviously a problem for that author. Also, if it was
not a problem, why would speed improvement be a major goal of
YARV/Ruby 2?

In some circumstances, a very good speed is appreciable.
In many circumstances, it's anecdotal, when responsiveness is desired,
it's better to focus on software design, language usage and many other
things etc.
Anyway, it's always better to have speed, everything else being equal.

Now, please come back to the subject of the thread, 'speed up ruby'.
Ruby is a language, not a program, a parser or something like this, a
language is defined by its syntax, its semantic etc., not by an
implementation.
Ruby goodness is in it's design, it seems to be well designed (well
written too, I read part of the sources), the focus semms to be on the
language, not on the implementation. You can change a parser, you
cannot change a language in its semantics so easily.

···

--
fr : http://patrick.davalan.free.fr/
en : http://harpo.free.fr/

6

irb$ parent.value += 1

I too am somewhat disappointed by this thread. People, we do *not*
need to be reminded that Ruby is slower than C . We *would* benefit
from serious discussion of how (or if) Ruby could be faster. Will
YARV do this? (The last time I saw any YARV benchmarks it performed
more slowly than Ruby 1.x on some tests. Has this changed? Will it
change?) Is there anything besides YARV that promises to address
performance or is YARV the only horse in the race? If I am
considering rewriting my Ruby in C for performance reasons, how can I
decide whether it is worth waiting for for YARV?

These are sensible questions. They deserve sensible answers. They
aren't getting them (not on this thread at any rate).

Lest I be accused of throwing stones from inside a glass house, let me
add a few links:

ruby-prof: <URL:http://ruby-prof.rubyforge.org/&gt;
Polishing Ruby: Space vs Time: <URL:http://blog.zenspider.com/archives/2005/04/space_vs_time.html&gt;
Zed on Ruby, Rails, Mongrel, and More: <URL:O'Reilly Media - Technology and Business Training;
  "I'll be honest right away though and say that Ruby is slow. The
   Ruby community has been ignoring the huge "performance" elephant
   standing in the room and they need to start talking about it so it
   goes away."

Regards,

Jeremy Henty

···

On 2006-07-14, Simon Kröger <SimonKroeger@gmx.de> wrote:

+1

I don't get why Jamal is called a troll here.

[...]

The original Poster was asking very specific things like
configurations, resources, memory limits, priorities and got

"Write it C."

as an answer. I would consider that trolling, and jamal seems to
think so too.

7

Simon Kröger wrote:

I would love ruby to be faster. How fast? I don't know, as fast as possible
I guess. I would even love C to be faster, and a lot of people spend a lot
of effort to make that happen (optimizing optimizers). There is nothing wrong
with that (not for C and not for ruby).

The original Poster was asking very specific things like configurations,
resources, memory limits, priorities and got

"Write it C."

as an answer. I would consider that trolling, and jamal seems to think so too.

cheers

Simon

gforth uses special features of gcc to achieve high speed.
A post from comp.lang.forth
(topic: Question from a newcomer - regarding words):

The default Debian gforth install they are using is still not turning
on many optimizations.

Actually the way that Gforth was built for Debian, even optimizations
that you don't have to turn on are disabled, in particular, dynamic
superinstructions. This causes Gforth to drop down in the CPU time
rank, but it helps in the memory consumption rank.

To give you an idea of how much this can hurt, here are the standard
Gforth benchmark numbers for 0.6.2 on a 2.26GHz Pentium 4:

siev bubble matrix fib
0.23 0.28 0.19 0.34 gcc-2.95.1; gforth-0.6.2 --enable-force-reg
0.79 1.01 1.11 1.14 Debian gforth 0.6.2-4

8

Austin Ziegler wrote:

Performance concerns must *always* be quantified to be addressed.

There's actually more to it than that, as Zed Shaw pointed out in one of his rants a while back. Not only do you have to quantify the performance of two alternatives you're comparing, you have to know what the metrics mean, how they relate to the economics of the system's users, *and* you have to know some statistics. You have to know how to tell when a difference in a metric is statistically significant, and you have to know what the factors are that affect performance metrics.

But the C program will typically be harder to maintain.

Maybe ... maybe not. Maintainability more or less equates to readability by humans, which more or less equates to documentation and discipline, rather than being language-specific. I'm sure you've seen highly maintainable C and Ruby code that could only be maintained by its author. Certainly the Ruby interpreter is an example of highly-maintainable C.

Since
you've admitted that you haven't studied CS, you may have missed the
mantra: beware premature optimisation.

There's an alternative mantra: build performance into your applications, just like you build correctness and usability into them. That implies, I think, frequent performance unit testing/benchmarking just as it implies the other kinds of unit testing. They used to teach people, "make it work, then make it pretty, then make it fast." I don't think that advice cuts it any more. I think you have to make it work, make it pretty and make it fast concurrently.

Of course, as a performance engineer, I get paid to make it fast, so I ignore the ugliness and often ignore defects that I know will get fixed and don't affect performance. :slight_smile:

9

The speed issue has been discussed many times on this list.

Many people find Ruby slow, including myself.
For some people it's fine.

But it always end up with people putting each other down and trying to
show how much of a "bad ass" they are because Ruby is fine for them in
their small world.
(This happens with EVERY big issue on this list, unless matz is here to
guide them)

My suggestion to anyone new or old that finds Ruby slow is this...

It will never get better by this group.

So either do it yourself or wait for someone/group that "gets it", that
Ruby is slow and have the power to make it better.
http://plas.fit.qut.edu.au/Ruby.NET/

Or just move on to .NET, PHP or Python.

I'm sure I'll get flamed...but it's what I expect from this group.

···

--
Posted via http://www.ruby-forum.com/.

10

TPFJ[1]

I believe Jamal is one of our visually impaired Ruby users and his
screen reader unfortunately currently doesn't do well with standard
"bottom-posted" quoted replies. Although it's not optimal, for now,
some folks tend to top-post when replying to individuals who are
blind.

---John

[1]: "Top Posting For Jamal"

···

On 7/16/06, Austin Ziegler <halostatue@gmail.com> wrote:

On 7/14/06, Jamal Mazrui <Jamal.Mazrui@fcc.gov> wrote:
[snip]

-austin
BTW, stop top-posting.

11

Good points. But I think the overall progress of this thread tends to
be:

class DeadHorse < Horse
    def turn_into_glue
        self.beat
    end
end

Harpo wrote:

···

(sorry for my poor english)

Jamal Mazrui wrote:

> Certainly, Ruby performance is not always a problem. It may not even
> be
> a problem in most situations.

Language performance is not a problem in many situations.

> The issue arises enough on the list,
> however, that, combined with personal experience, I am convinced it is
> a
> significant problem. I think Ruby has few problems compared to other
> languages, but this is probably its biggest one.

you are 'convinced', you 'think', 'probably' ...
Many people were convinced of things which are false or at least not
true, I was too. It doesn't worth benchmarks.

> Quantifying it more
> than that is difficult, and should not be necessary for it to be
> acknowledged as a valid concern.

Quantifying is not that difficult for some specialized use of a
language, Ruby is a general purpose language.
If you use it for scripting, say something like scanning logs, it
doesn't even worth spending 1 day benchmarking to know which of Ruby,
Perl & friends will save or lose 1 millisecond of CPU time in a year.
For desktop application, if the user have it's response in a tenth of a
second instead of 2 tenth of a second you don't save half of the time,
you just do not save nothing for obvious reasons.

> Since the message that began this thread asked how to speed up Ruby
> programs, it was obviously a problem for that author. Also, if it was
> not a problem, why would speed improvement be a major goal of
> YARV/Ruby 2?

In some circumstances, a very good speed is appreciable.
In many circumstances, it's anecdotal, when responsiveness is desired,
it's better to focus on software design, language usage and many other
things etc.
Anyway, it's always better to have speed, everything else being equal.

Now, please come back to the subject of the thread, 'speed up ruby'.
Ruby is a language, not a program, a parser or something like this, a
language is defined by its syntax, its semantic etc., not by an
implementation.
Ruby goodness is in it's design, it seems to be well designed (well
written too, I read part of the sources), the focus semms to be on the
language, not on the implementation. You can change a parser, you
cannot change a language in its semantics so easily.

--
fr : http://patrick.davalan.free.fr/
en : http://harpo.free.fr/

12

This is an excellent remark, unfortunately it is wrong in the human sense
of things,
90% of us were thinking "Ruby Implementation", and this is a valid thing to
discuss.
Rite for example, etc. etc.
But I really want to back up your point.
Even if we were to decide that all existing Ruby Implementations were too
slow -- and most of us
including myself do not -- we should
still recognize the beauty of the design of Ruby itself and although it is
off topic unless we are word pickers I think
it is not mentioned often enough.

So in order not to make my post completely off topic, I was wondering if
someone willing and capable to speed up
implementations might not be better adviced to think about Rite or Parrot
(flamesuit on, np, go ahead ;).

Cheers
Robert

···

On 7/17/06, Harpo <invalid@invalid.invalid> wrote:

[SNIP]
Now, please come back to the subject of the thread, 'speed up ruby'.
Ruby is a language, not a program, a parser or something like this, a
language is defined by its syntax, its semantic etc., not by an
implementation.

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

13

Hi,

I too am somewhat disappointed by this thread. People, we do *not*
need to be reminded that Ruby is slower than C . We *would* benefit
from serious discussion of how (or if) Ruby could be faster. Will
YARV do this? (The last time I saw any YARV benchmarks it performed
more slowly than Ruby 1.x on some tests. Has this changed? Will it
change?) Is there anything besides YARV that promises to address
performance or is YARV the only horse in the race?

There is Ruby2CExtension (http://ruby2cext.rubyforge.org/\), one of it's goals is to provide an easy way to speed up Ruby scripts or libraries.

The first version didn't have any real optimizations and consequently didn't produce significant speed ups. But I have now implemented some optimizations, that provide very significant speed ups for some cases (see http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/201642 for example).

I think it is not realistic to hope for such extreme speed ups for real world applications or libraries, but speed ups of 2x to 3x should be possible for many cases.

Ruby2CExtension doesn't support 100% of Ruby's features, but it supports enough to handle real world libraries. It can compile Austin Ziegler's PDF::Writer for example (with some small changes). The resulting C extension is about 33% faster (i.e. 3s instead of 4s) than the Ruby code.

I hope to make a new release soon, in the mean time you can checkout the latest revision from svn://rubyforge.org/var/svn/ruby2cext/trunk.

Dominik

···

On Sat, 15 Jul 2006 00:25:23 +0200, Jeremy Henty <jeremy@chaos.org.uk> wrote:

14

William James wrote:

gforth uses special features of gcc to achieve high speed.
A post from comp.lang.forth
(topic: Question from a newcomer - regarding words):

The default Debian gforth install they are using is still not turning
on many optimizations.
    
Actually the way that Gforth was built for Debian, even optimizations
that you don't have to turn on are disabled, in particular, dynamic
superinstructions. This causes Gforth to drop down in the CPU time
rank, but it helps in the memory consumption rank.

To give you an idea of how much this can hurt, here are the standard
Gforth benchmark numbers for 0.6.2 on a 2.26GHz Pentium 4:

siev bubble matrix fib
0.23 0.28 0.19 0.34 gcc-2.95.1; gforth-0.6.2 --enable-force-reg
0.79 1.01 1.11 1.14 Debian gforth 0.6.2-4
  

Comments:

1. The "enable-force-reg" optimization has some risks on some architectures. I'm not at all familiar with the details, I just know that the Gentoo "gforth" package issues warnings if you choose that optimization. And gcc 2.95 probably isn't the compiler you want to be using. (You probably don't want to be using gcc 4 either, unless you're on a 64-bit real machine, but that's another ball of snakes.)

2. There is/was a project to build a Ruby virtual machine using the "gforth-like" technology "vmgen". IIRC "vmgen" is part of the gforth package, as is the documentation on it, so if you have gforth you probably have vmgen as well.

3. Most of the Ruby VM activity these days seems to be in three other areas: YARV, Cardinal (Ruby hosted by Parrot) and JRuby (Ruby hosted by the JVM). The "vmgen" based project is in the round-off noise. "vmgen" performs much better when the virtual machine is stack-based rather than register-based, and I'm not sure which is optimal for the Ruby language. My best guess is that YARV is the horse to bet on ... assuming, as I don't, that a VM is the best route to Ruby speed. :slight_smile:

15

Hi,

···

In message "Re: How to speed up ruby and make it as fast as possible" on Sun, 16 Jul 2006 18:16:23 +0900, Reggie Mr <buppcpp@yahoo.com> writes:

My suggestion to anyone new or old that finds Ruby slow is this...

It will never get better by this group.

Agreed. Saying it's slow is far easier to make it fast. I know it's
slow. We are working for it. What can I say more.

Blaming, beating, or even insulting us would never help performance.

              matz.

16

I'd love to hear what those changes are.

-austin

···

On 7/14/06, Dominik Bathon <dbatml@gmx.de> wrote:

Ruby2CExtension doesn't support 100% of Ruby's features, but it supports
enough to handle real world libraries. It can compile Austin Ziegler's
PDF::Writer for example (with some small changes). The resulting C
extension is about 33% faster (i.e. 3s instead of 4s) than the Ruby code.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

17

Would that *all* managers knew this! :wink:

So what *would* help? Working on some of the YARV test case failures,
for instance?

Regards,

Jeremy Henty

···

On 2006-07-16, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Blaming, beating, or even insulting us would never help performance.

18

Firstly, I want to make clear that I agree with Matz's point here.

What I find amazing in this thread is how far from the original
question it got, without even scratching the surface of the initial
question.

The OP asked: I have a server, a Ruby app, is anything I can do to
make the app use more resources of my server.

I would say that in the world I am come from, or maybe in an ideal
world I would say:
- have you identified which parts are slow for you? I mean what is
performing bad from your business perspective?
- if not, than I would ask how can I figure out which parts are the
slowest for the scenarios I want more speed
- if yes, I would point my finger to the problem and ask if there is
any knowledge on how to speed up those fragment. If not, than what
alternatives I can take.

(but here I haven't even figured out what the app is about, or I
completely missed it).

Once again, going back to my world if an app works badly from the
client perspective, than I start looking at the app, I start looking
at the confs (maybe I really have bad configurations), I look at the
overall architecture (maybe I am doing too much networking, etc.).

Ruby execution, like any other PL, has a known speed. You must take
care that your app is following the best principles and come as close
as optimal. Than you need to look at all the pieces of the puzzle. If
somebody wants to blame the speed of the PL/environment than I would
say that they made a very wrong initial decission and nothing will
help him out.

just my 2 eurocents,

./alex

···

On 7/16/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: How to speed up ruby and make it as fast as possible" > on Sun, 16 Jul 2006 18:16:23 +0900, Reggie Mr <buppcpp@yahoo.com> writes:

>My suggestion to anyone new or old that finds Ruby slow is this...
>
>It will never get better by this group.

Agreed. Saying it's slow is far easier to make it fast. I know it's
slow. We are working for it. What can I say more.

Blaming, beating, or even insulting us would never help performance.

                                                        matz.

--
.w( the_mindstorm )p.

19

Yukihiro Matsumoto wrote:

Hi,

>My suggestion to anyone new or old that finds Ruby slow is this...
>
>It will never get better by this group.

Agreed. Saying it's slow is far easier to make it fast. I know it's
slow. We are working for it. What can I say more.

Blaming, beating, or even insulting us would never help performance.

              matz.

One thing that would really help is a "standard Ruby benchmark suite" that one could use to quickly compare alternative implementations. Since it's a little unclear to me what the "target market focus" is for the language, I'll invite the members of this list to post what they think should be in such a suite. Although it's an obvious "answer", I think I'd prefer to leave Rails out of the mix, because Rails performance depends on both a web server and a database directly, and the server OS, client/browser and network bandwidth indirectly.

So ... what should be in a "standard Ruby benchmark suite?" Does such a thing exist already?

···

In message "Re: How to speed up ruby and make it as fast as possible" > on Sun, 16 Jul 2006 18:16:23 +0900, Reggie Mr <buppcpp@yahoo.com> writes:

20

Alexandru Popescu wrote:

Firstly, I want to make clear that I agree with Matz's point here.

What I find amazing in this thread is how far from the original
question it got, without even scratching the surface of the initial
question.

There was more than one question in the OP. The last question in the OP was, "[a]lso is there anything else I can do to get the most speed out of ruby? "

Hence the wide range of responses.

···

--
James Britt

"In Ruby, no one cares who your parents were, all they care
  about is if you know what you are talking about."
   - Logan Capaldo