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

Ruby
#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

#2

Jamal M. wrote:

not a problem, why would speed improvement be a major goal of YARV/Ruby
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

On 2006-07-14, Simon Kröger [email protected] wrote:

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

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/
Polishing Ruby: Space vs Time:
URL:http://blog.zenspider.com/archives/2005/04/space_vs_time.html
Zed on Ruby, Rails, Mongrel, and More:
URL:http://www.oreillynet.com/ruby/blog/2006/05/post.html
“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 H.

#4

Hi,

On Sat, 15 Jul 2006 00:25:23 +0200, Jeremy H. [email protected]
wrote:

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 Z.'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

#5

Simon Kröger wrote:

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

#6

On 7/14/06, Jamal M. [email protected] 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.

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.

#7

William J. wrote:

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:

#8

On 7/14/06, Dominik B. [email protected] wrote:

Ruby2CExtension doesn’t support 100% of Ruby’s features, but it supports
enough to handle real world libraries. It can compile Austin Z.'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’d love to hear what those changes are.

-austin

#9

Austin Z. wrote:

Performance concerns must always be quantified to be addressed.
There’s actually more to it than that, as Zed S. 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:

#10

Jamal M. 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.

#11

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 [email protected]
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.
#12

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.

#13

On 2006-07-16, Yukihiro M. [email protected] wrote:

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

Would that all managers knew this! :wink:

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

Regards,

Jeremy H.

#14

On 7/16/06, Yukihiro M. [email protected] wrote:

slow. We are working for it. What can I say more.

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

                                                    matz.

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

#15

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”

#16

Alexandru P. 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 B.

“In Ruby, no one cares who your parents were, all they care
about is if you know what you are talking about.”

  • Logan C.
#17

On Jul 16, 2006, at 8:43 AM, Alexandru P. wrote

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.

I did some profiling on my code and the real bottle neck is using the
Net::HTTP library. I’m using it to grab HTML from a website. Our
server is located in Boston and after doing a digg I came to found
out the server we are communicating with is located in LA. I realize
the communication between the 2 servers is something I can not speed
up, as our server is in a very nice data center with 6 T3s. But I
would still like to speed up Ruby as much as possible. Am I wrong here?

Lastly, I read in another thread that the Net::HTTP library was
actually slow and using something like curl is faster. Is this correct?

Anyways, going back to my original post. I am new to ruby and I just
wanted to make sure that I was getting the most out of it. I was
uncertain if ruby had a configuration file or any kind of
configuration that would keep it from using ALL of your computer’s
resources.

Thanks for the help.

Thank You,
Ben J.
E: [email protected]

#18

On Sun, 16 Jul 2006 09:40:47 +0200, Austin Z.
[email protected]
wrote:

On 7/14/06, Dominik B. [email protected] wrote:

Ruby2CExtension doesn’t support 100% of Ruby’s features, but it supports
enough to handle real world libraries. It can compile Austin Z.'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’d love to hear what those changes are.

Here they are:

diff -ruw lib_orig/pdf/writer/fontmetrics.rb
lib/pdf/writer/fontmetrics.rb
— lib_orig/pdf/writer/fontmetrics.rb 2005-06-16 06:28:25.000000000
+0200
+++ lib/pdf/writer/fontmetrics.rb 2006-07-08 01:33:40.000000000
+0200
@@ -57,6 +57,7 @@
font = nil
afm = nil

  • resss = nil
    metrics_path.each do |path|
    afm_file = File.join(path, “#{name}.afm”).gsub(/.afm.afm$/o,
    “.afm”)
    rfm_file = “#{afm_file}.rfm”
    @@ -67,7 +68,8 @@
    if File.exists?(rfm_file)
    data = File.open(rfm_file, “rb”) { |file| file.read }
    font = Marshal.load(data)
  •      return font

  •      resss = font

  •      break
    end
  rescue
    nil

@@ -188,6 +190,7 @@
end rescue nil # Ignore file errors
break unless font.nil?
end

  • return resss if resss

    raise ArgumentError, “Font #{font_name} not found.” if font.nil?
    font

This is because return from inside a block is not supported.

diff -ruw lib_orig/pdf/writer.rb lib/pdf/writer.rb
— lib_orig/pdf/writer.rb 2005-09-07 19:01:14.000000000 +0200
+++ lib/pdf/writer.rb 2006-07-08 01:34:32.000000000 +0200
@@ -1687,7 +1687,7 @@
tw = width / size.to_f * 1000

  pos = -1
  • loop do
  • while true
    pos += 1
    break if pos == text.size
    font_change = true

Again because return from inside a block is not supported (so I just
changed the block to a while loop).

diff -ruw lib_orig/transaction/simple.rb lib/transaction/simple.rb
— lib_orig/transaction/simple.rb 2005-05-05 18:16:49.000000000
+0200
+++ lib/transaction/simple.rb 2006-07-08 01:33:00.000000000 +0200
@@ -650,7 +650,8 @@
if respond_to?(:instance_variable_get)
instance_variable_set(vv, rr.instance_variable_get(vv))
else

  •      instance_eval(%q|#{vv} = rr.instance_eval("#{vv}")|)

  •      $__________xxxxxxxx___rr = rr

  •      instance_eval(%q|#{vv} =

$__________xxxxxxxx___rr.instance_eval("#{vv}")|)
end
end

This is because the instance_eval wouldn’t see the local variable rr.

That’s all that I changed to get it to compile and the resulting C
extension seems to work correctly with the demos.

Dominik

#19

Yukihiro M. wrote:

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?

#20

Ben J. wrote:

I did some profiling on my code and the real bottle neck is using the
Net::HTTP library. I’m using it to grab HTML from a website. Our server
is located in Boston and after doing a digg I came to found out the
server we are communicating with is located in LA. I realize the
communication between the 2 servers is something I can not speed up, as
our server is in a very nice data center with 6 T3s. But I would still
like to speed up Ruby as much as possible. Am I wrong here?

Lastly, I read in another thread that the Net::HTTP library was actually
slow and using something like curl is faster. Is this correct?
Yes, but if you have a look through that thread, there was a specific
change mentioned that you can make in the library to speed up Net::HTTP.
From the top of my head (you may wish to check this), it was changing
the buffer size in BufferedIO#rbuf_fill from 1024 to 8192.

Why that’s a constant, I don’t know…