Asp Forum - question on bottleneck of ruby

Roger Pack

9/5/2007 7:47:00 PM

Question: if I made the statement "Ruby is slower than some other
interpreted languages" almost anyone could agree with it (slower
computationally, not programmer time-wise).
So my question is...where is the bottleneck? Is it in method lookup?
Is it that method lookup is more frequent, since everything is an
object? Is it in parsing? Storage? Just wondering. Thanks!
-Roger
--
Posted via http://www.ruby-....

18 Answers

khaines

9/5/2007 9:43:00 PM

Roger Pack

9/27/2007 3:41:00 PM

Thanks Kirk.

Follow-up question: it seems like there have been a lot of 'replacement
attempts' of the Ruby interpreter, but none of them seem to have really
really sped it up (jruby, rubinius, etc.) They do add cool features like
thread safeness or what not, and in certain instances are faster, but
not like 'we've overcome the bottleneck!' faster.
Does this mean that they suffer from the same bottlenecks? Is Ruby just
a hard language to optimize for? Do they all tree walk and have slow
method dispatch and a slow GC or something? Hmm.

Stay well.
-Roger
>> So my question is...where is the bottleneck? Is it in method lookup?
> The dynamic nature of the method dispatch. The overall implementation
> --
> both the tree walker versus a vm, and some of the implementation
> details.
> The GC can also be a bottle neck. It stops the world when it runs, and
> it
> has to touch every object when it runs, so as the program gets bigger
> (in
> object count), the GC burden gets higher.
>
--
Posted via http://www.ruby-....

Richard Conroy

9/27/2007 5:00:00 PM

On 9/27/07, Roger Pack <rogerpack2005@gmail.com> wrote:
> Thanks Kirk.
>
> Follow-up question: it seems like there have been a lot of 'replacement
> attempts' of the Ruby interpreter, but none of them seem to have really
> really sped it up (jruby, rubinius, etc.)

I don't think that the developers of the alternatives would consider themselves
as 'replacements' or 'competitors'. With the possible exception of Rubinius.
But that's its intent - to be the replacement MRI for Ruby 2.0; in the meantime
YARV (1.9) is the Ruby Interpreter based on the current code base. There have
been a number of synthetic benchmarks that show interesting performance
improvements in YARV currently. I am not sure how it stacks up in real
world use though. (Not being critical here, real-world benchmarks are
notoriously
difficult to do right).

> Does this mean that they suffer from the same bottlenecks? Is Ruby just
> a hard language to optimize for? Do they all tree walk and have slow
> method dispatch and a slow GC or something? Hmm.

You should definitely keep up to date with the JRuby guy's blogs (Ola Bini
and Charles Oliver Nutter). They have been quite detailed on this topic
over the last few months. While their solutions for performance are to make
JRuby very compatible with the JVM, they articulate the particular reasons
for Ruby's weak performance.

Basically, Ruby is hard to optimise for. It's super dynamic nature (Open
Classes) mean that traditional compiler/interpreter tricks cannot be used.

Markus Schirp

9/27/2007 5:16:00 PM

On Fri, 28 Sep 2007 01:59:36 +0900
"Richard Conroy" <richard.conroy@gmail.com> wrote:

> On 9/27/07, Roger Pack <rogerpack2005@gmail.com> wrote:
> > Thanks Kirk.
> >
> > Follow-up question: it seems like there have been a lot of
> > 'replacement attempts' of the Ruby interpreter, but none of them
> > seem to have really really sped it up (jruby, rubinius, etc.)
>
> I don't think that the developers of the alternatives would consider
> themselves as 'replacements' or 'competitors'. With the possible
> exception of Rubinius. But that's its intent - to be the replacement
> MRI for Ruby 2.0; in the meantime YARV (1.9) is the Ruby Interpreter
> based on the current code base. There have been a number of synthetic
> benchmarks that show interesting performance improvements in YARV
> currently. I am not sure how it stacks up in real world use though.
> (Not being critical here, real-world benchmarks are notoriously
> difficult to do right).
>
> > Does this mean that they suffer from the same bottlenecks? Is Ruby
> > just a hard language to optimize for? Do they all tree walk and
> > have slow method dispatch and a slow GC or something? Hmm.
>
> You should definitely keep up to date with the JRuby guy's blogs (Ola
> Bini and Charles Oliver Nutter). They have been quite detailed on
> this topic over the last few months. While their solutions for
> performance are to make JRuby very compatible with the JVM, they
> articulate the particular reasons for Ruby's weak performance.
>
> Basically, Ruby is hard to optimise for. It's super dynamic nature
> (Open Classes) mean that traditional compiler/interpreter tricks
> cannot be used.
>

So why not add a "class freeze method", so that these traditional
compiler/interpreter tricks can be used?

During development you just not activate this "frozen class state", for
releases you can freeze some "performance penalty" classes.
So we not loose ruby's super-dynamic character (during development),
and got the benefits from more agressive optimisations.

Richard Conroy

9/27/2007 6:09:00 PM

On 9/27/07, Markus Schirp <mbj@seonic.net> wrote:
> On Fri, 28 Sep 2007 01:59:36 +0900
> "Richard Conroy" <richard.conroy@gmail.com> wrote:
> > Basically, Ruby is hard to optimise for. It's super dynamic nature
> > (Open Classes) mean that traditional compiler/interpreter tricks
> > cannot be used.
> >
>
> So why not add a "class freeze method", so that these traditional
> compiler/interpreter tricks can be used?

IIRC you can set how open your classes are at runtime. Though
we *like* the fact that Ruby classes are open at runtime. Its not
a development feature by any means - Rails makes huge use of
this.

Interpreter writers know this and design accordingly. So they use
non-traditional tricks instead.

Mostly I just don't see Ruby performance as a significant issue.
Memory management and GC would be higher on my priority list,
and are arguably easier to solve anyway.

JRuby now adds another option for dropping down to system
language performance for specific cases. .NET users will get
similar treatment eventually, and yet another system language
option will be added to the mix (and .NET users will get a
proper scripting option on the CLR as well ;-P )

The only area where I have noticed very poor Ruby performance
is in REXML. Though REXML is very much an entry-level option,
and the authors themselves would redirect you to alternatives if
your needs are greater. My observations were probably multiplied
by my absolutely rubbish XML skills too....

Charles Oliver Nutter

9/28/2007 12:19:00 AM

Clifford Heath

9/28/2007 2:51:00 AM

Charles Oliver Nutter wrote:
> The fact that classes are open doesn't really impact Ruby performance
> all that much.

That's true for single-process benchmarks where you don't implement
sharing of compiled modules. In a compiler-interpreter I once worked
on, we serialised the bytecode to a memory-mappable file for each
cluster of modules, which did a lot to improve startup performance,
especially for subsequent instances. Not possible for Ruby however,
doe to the open classes - QED.

The other performance factor (related to a different discussion) that
makes byte-code interpretation faster than AST-interpretation is that
with byte-code, you get much better locality of reference, so your
cache+memory system works much better. This is a *very* significant
factor that justifies some recent complaints. It's also quite possible
for Ruby interpreters to implement, despite open classes.

Clifford Heath.

M. Edward (Ed) Borasky

9/28/2007 3:37:00 AM

Francis Cianfrocca wrote:

> I agree with Kirk. Ruby's inherent performance bottleneck is also its most
> distinctive feature: the open classes and data structures. There's always
> going to be a limit to how much faster you can do name-resolution at
> runtime, since it's costly to begin with, and you can't deterministically
> predict it. (There are approaches to adaptively predict name-bindings at
> runtime, notably from Smalltalk, and I expect JRuby will be able to leverage
> them. But they can ameliorate, not solve, the fundamental issue.)

Which is why they teach data structures in computer science class. It's
all about fast search, I think. That's one of the big gripes I have with
"lazy" interpretation. If you don't do stuff until you have to do it, it
only pays off if you end up *never* having to do it. :)

[snip]

> I used to believe that large Ruby programs could be constructed as
> independent coarse-grained modules running in their own processes,
> communicating through message-passing. Having done quite a bit of this now,
> I think the approach helps quite a bit, but still suffers from memory usage.
> It's hard to get the memory-usage of even a small Ruby program down to a
> level that would permit (perhaps) hundreds of cooperative processes to be
> running at once.

And unless the Ruby "inner interpreter" is highly optimized, even if you
have only one copy of the text segment and only one copy of all the
libraries in RAM, you're *really* unlikely to have all the "good stuff"
in the tiny caches processors have.

> Bottom line: using Ruby will always be characterized by a tradeoff between
> performance and programmer productivity. This is not a criticism of Ruby in
> any way, shape or form! Productivity is a fundamental engineering value, and
> time-to-market is a fundamental quality dimension. Ruby therefore has, and
> will continue to have, a unique value proposition.

I'm not sure this is a valid tradeoff. The economics of *development*
and the economics of *operating* a large code are two entirely different
subjects. People have "always" prototyped in "slow but productive"
languages, like Lisp, Perl, PHP and Ruby, and then reached a point where
the economics dictated a complete rewrite for speed into C, C++ or Java.
I can think of more examples of this than I can of something that was
developed and prototyped rapidly and then grew by "just throwing more
hardware at inefficient software."

So ... just like a startup should plan for the day when a big company
offers them the choice of selling out or being crushed like a bug, when
you implement a great idea in some rapid prototyping framework like
Rails, plan for the day when you are offered the choice of rewriting
completely in a compiled language or going bankrupt buying hardware.

Charles Oliver Nutter

9/28/2007 4:21:00 AM

Clifford Heath wrote:
> Charles Oliver Nutter wrote:
>> The fact that classes are open doesn't really impact Ruby performance
>> all that much.
>
> That's true for single-process benchmarks where you don't implement
> sharing of compiled modules. In a compiler-interpreter I once worked
> on, we serialised the bytecode to a memory-mappable file for each
> cluster of modules, which did a lot to improve startup performance,
> especially for subsequent instances. Not possible for Ruby however,
> doe to the open classes - QED.

Startup time does not general performance make. Just ask Java :)

> The other performance factor (related to a different discussion) that
> makes byte-code interpretation faster than AST-interpretation is that
> with byte-code, you get much better locality of reference, so your
> cache+memory system works much better. This is a *very* significant
> factor that justifies some recent complaints. It's also quite possible
> for Ruby interpreters to implement, despite open classes.

JRuby has successfully implemented a full Ruby 1.8 to Java bytecode
compiler (as of about ten minutes ago), so it is indeed possible...and
nicely fast.

- Charlie

M. Edward (Ed) Borasky

9/28/2007 4:45:00 AM

M. Edward (Ed) Borasky wrote:
> Francis Cianfrocca wrote:
>> Bottom line: using Ruby will always be characterized by a tradeoff
>> between
>> performance and programmer productivity. This is not a criticism of
>> Ruby in
>> any way, shape or form! Productivity is a fundamental engineering
>> value, and
>> time-to-market is a fundamental quality dimension. Ruby therefore has,
>> and
>> will continue to have, a unique value proposition.
>
> I'm not sure this is a valid tradeoff. The economics of *development*
> and the economics of *operating* a large code are two entirely different
> subjects. People have "always" prototyped in "slow but productive"
> languages, like Lisp, Perl, PHP and Ruby, and then reached a point where
> the economics dictated a complete rewrite for speed into C, C++ or Java.
> I can think of more examples of this than I can of something that was
> developed and prototyped rapidly and then grew by "just throwing more
> hardware at inefficient software."
>
> So ... just like a startup should plan for the day when a big company
> offers them the choice of selling out or being crushed like a bug, when
> you implement a great idea in some rapid prototyping framework like
> Rails, plan for the day when you are offered the choice of rewriting
> completely in a compiled language or going bankrupt buying hardware.
>
>

OK ... so ... is Twitter in trouble?

http://www.scripting.com/stories/2007/09/27/twitterIsTakingAShowe...

"I have seen the future, and it's just like the present, only longer."
-- Kehlog Albran

comp.lang.ruby

question on bottleneck of ruby

Roger Pack

khaines

Roger Pack

Richard Conroy

Markus Schirp

Richard Conroy

Charles Oliver Nutter

Clifford Heath

M. Edward (Ed) Borasky

Charles Oliver Nutter

M. Edward (Ed) Borasky

x Login to ForumsZone