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

Ruby
21

M. Edward (Ed) Borasky wrote:

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?

I’ve never heard of one, but I can’t think of anyone better than a
professional performance consultant to drive one :slight_smile:

If they were to be chosen as the focal point for performance
improvement, the things I’d benefit most from being benchmarked are:

  • REXML
  • Mechanize
  • WEBrick
  • Test::Unit

I’ve pointed out higher-level libraries rather than core because they
exercise more of Ruby with fewer data points. Is that the right
approach? I realise that one downfall of this perspective is that the
library authors may have avoided certain techniques precisely because
they are too slow in the current Ruby implementation, so those
techniques would be completely sidelined. Continuations are one that
instantly spring to mind - I can only find callcc used in one file in
the stdlib.

An alternative would be to use rubicon’s full run time as the benchmark

  • that way we know that all the language features are being flexed, but
    some might get too much weighting.

Thoughts?

22

Alex Y. wrote:

I’ve never heard of one, but I can’t think of anyone better than a
professional performance consultant to drive one :slight_smile:
Well, I’m on the YARV mailing list, and I just saw a message go by on a
similar subject. They do have a benchmark they use, which looks like a
mix of “traditional” small benchmarks like Tower of Hanoi and some
benchmarks designed to deliberately exercise Ruby internals. I’m going
to see if I can get a copy and have a look at it. No sense re-inventing
a wheel, especially if four of them make YARV go faster. :slight_smile:

If they were to be chosen as the focal point for performance
improvement, the things I’d benefit most from being benchmarked are:

  • REXML
  • Mechanize
  • WEBrick
  • Test::Unit
    Yeah, those look like “typical Ruby tasks” to me.
    An alternative would be to use rubicon’s full run time as the
    benchmark - that way we know that all the language features are being
    flexed, but some might get too much weighting.

Thoughts?
A benchmark is little different from an automated unit test. The
“assertions” are simply replaced with (hopefully accurate) timings. It’s
a little more complicate than that, but that’s the general idea. Once
you have a suite of benchmarks, the interesting thing is that some
tunings to the “compiler” or the runtime environment will make tests
uniformly better, some uniformly worse and some will induce “tradeoffs”.
That’s where the statistics comes in – reducing a list of relative
performance numbers to a single “figure of merit”, usually with some
weighting based on known usage patterns.

23

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

24

(sorry for my poor english)

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

25

On 7/17/06, Harpo [email protected] 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.

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

–
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