Hi
Why people say that Ruby is a slow language? And is there any plans to
make it perfrom better in the near future? I was trying to start
learning it and someone told me it is slow and I really look for
something with high performance.
Thanks.
Like most things, “Ruby is slow” doesn’t have a black and white answer.
You’ve gotta know a little bit of history. Ruby 1.8.x is called “MRI,”
for
“Matz’s Ruby Interpreter.” Now, Matz is a great language designer, but
a
mediocreinterpreter implementor. So, starting with Ruby 1.9, we have
“YARV,” (or sometimes ‘KRI’) which is ‘yet another ruby vm’ or ‘koichi’s
ruby interpreter’. It’s been totally re-written by people who actually
care
about making Ruby as fast as possible. So the 1.8 to 1.9 gap is pretty
big,
check it out:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=ruby&lang2=yarv
That’s
not even taking into account the other Ruby implementations, such as
Rubinius, which uses a JIT, and is already pretty damn fast, or JRuby,
which
is currently the fastest Ruby implementation.
Another component of “Ruby is slow” is the whole “does it matter?”
question.
I use Ruby mostly in a web context, and so my database calls tend to be
the
slowest point of any given request, not Ruby itself. Basic Amdahl’s law
stuff; an infinitely fast Ruby would only be marginally better at
serving
pages. Even for most desktop apps, we’re increasingly in a world of 2GHz
mutli-core wonder machines, and the difference in microbenchmarks just
doesn’t actually matter. That’s not to say that it NEVER does; my kernel
project, for example, isn’t in Ruby, that’d be silly. I would never use
Ruby
for scientific computing, or crunching really large numbers. My startup
does
some file processing stuff; most of the site is in Rails, but that
processing is done in C. It just makes sense.
The last component is “Why is Ruby kinda slow?” Because Ruby is possibly
the
most dynamic language ever created, it’s a fucking nightmare to
optimize.
All of those wonderful features that let me develop things really
quickly
and have really clean, beautiful code are an absolute bitch from an
implementation standpoint. I can give you a few examples if you’re
curious,
I don’t know how much of a compiler/language geek you are.
Anyway, I’m almost rambling. If you want to know anything else / get
some
clarification, ask away. Ruby is my favorite language (followed closely
by
Haskell), so anything to help spread awareness and shine some light on
the
actual details!
On Wed, Nov 3, 2010 at 12:54 PM, Ruby Me [email protected] wrote:
–
Posted via http://www.ruby-forum.com/.
Ruby 1.8 was, I think, the slowest widely used language in the world.
They
put a lot of work into it, and Ruby 1.9 is around 4 times faster, and is
basically equivalent in speed to other dynamic languages (ie Python,
Perl,
PHP). Depending on your use case, other implementations like JRuby,
MacRuby,
and Rubinius, may also be even faster.
What are you working on? If you’re doing systems level programming or
heavy
math computing, then Ruby isn’t a good choice. For pretty much
everything
else, it works just fine. For some cases like web, it is a great choice.
If
you find that it doesn’t perform, you can profile your code to see where
the
bottleneck is occurring, then optimize that spot (even dropping into a
lower
language if necessary).
There are other tradeoffs to consider, though. If you select another
language, what you gain in speed, you may lose in environment. Ruby is
is an
absolute delight to program in, and supports extremely powerful
abstractions
that let you concisely express a concept, and that expression is all
that is
needed to implement it. Check out things like Sinatra (
http://www.sinatrarb.com/) and Shoes (http://shoesrb.com/) to see what I
mean.
Also, depending on what you are trying to do, Ruby’s speed probably
doesn’t
matter, because you’ll be using gems that are fast since they wrap low
level
libraries. I still get to use low level C libraries like libxml, but I
don’t
have to deal with C, I get to use them through an elegant Ruby wrapper
like
Nokogiri. I get the speed advantage and the environment / interface
advantage.
That said, I still think there is hope for static languages, I just
don’t
know of any right now that would be worth putting up with. And Ruby can
also
get better (especially as more people show interest in it), if Smalltalk
and
Lisp can be so fast, then I think Ruby can too. If the world hadn’t
abandoned Smalltalk, that might be a language worth checking out.
Of course, speed in the future is probably going to be based more on how
well your language can deal with concurrency, so in that regard, you
might
choose a language explicitly intended to address this, like Clojure (If
you
watch the screencast http://clojure.blip.tv/ at 38:30, Rich Hickey tells
this story where he does the traveling salesman on a java machine, and
it
uses 600 cores!). If you think that is the case, then it isn’t much of a
step to assume low level languages with poor support for concurrency
will
fall behind, speedwise, in the future. Concurrency is hard in C, but
it’s
trivial in Clojure.
Of course, good luck finding a job doing Clojure. If you care about the
job
market, pick up a Java book and kiss your soul goodbye 
(I actually
don’t
hate Java, it just has a lot of things that could be much nicer. If it
wasn’t for the JVM, though, Java wouldn’t have anything to offer, and
fortunately, the JVM is not restricted to Java)
(hey, Steve, I think I ended up rambling too!)
On Nov 3, 4:11 pm, Steve K. [email protected] wrote:
about making Ruby as fast as possible. So the 1.8 to 1.9 gap is pretty big,
check it
out:http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=rub…
That’s
not even taking into account the other Ruby implementations, such as
Rubinius, which uses a JIT, and is already pretty damn fast, or JRuby, which
is currently the fastest Ruby implementation.
are you sure jruby is the fastest?
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=jruby
it uses tons more memory and still is usually slower than 1.9.
It’s quite possible that something has changed recently that I’m not
aware
of.
Why people say that Ruby is a slow language? And is there any plans to
make it perfrom better in the near future? I was trying to start
learning it and someone told me it is slow and I really look for
something with high performance.
Well, it does have that reputation. But, slower than what? Obviously
it’s going to be slower than compiled languages like C. And, when
running on what? Since clearly it depends on the hardware you run it on.
Personally I think it’s better to talk in terms of efficiency rather
than speed. And if it’s true that Ruby sacrifices a little speed to
give the programmer a language that is a pleasure to use and debug in,
I’m personally happy with that.
On Nov 3, 5:04pm, Josh C. [email protected] wrote:
Ruby 1.8 was, I think, the slowest widely used language in the world. They
put a lot of work into it, and Ruby 1.9 is around 4 times faster, and is
basically equivalent in speed to other dynamic languages
it’s a very nice implementation indeed. It’s slower than Racket:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=racket
but that’s because they cheat by writing with (lots) of low-level,
ugly, imperative unsafe operations, same for SBCL Lisp:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=sbcl
That said, I still think there is hope for static languages, I just don’t
know of any right now that would be worth putting up with. And Ruby can also
get better (especially as more people show interest in it), if Smalltalk and
Lisp can be so fast, then I think Ruby can too.
Lisp cheats by simply pinning down types and using unsafe, low-level
fast operators when needing performance. In other words, it trades
its dynamically typed nature for performance when needed. and ugly,
low-level code…
BTW, I think all scripting languages – heck!, any high level language
indeed – should be measured against Lua. Its LuaJIT implementation
is astounding:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=luajit
despite being very high level, as dynamically typed and as concise as
ruby or python, it allow for almost C-like performance:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=luajit&lang2=gpp
It beats the crap out of java, specially in memory usage and code
size:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=luajit&lang2=java
no wonder its the favorite scripting language of the games industry…
On Wed, Nov 3, 2010 at 8:43 PM, Peter Lane
[email protected]wrote:
Another nice thing about JRuby is it gives you access to Java. And it’s
easy, and it still feels like Ruby.
If you have a program that takes a while to run, I think jruby is worth
trying. I often find small benchmarks show ruby 1.9 and jruby fairly
close, but anything more substantial and I get a consistent 2.5-3 times
speed up using jruby - these speedups are for fairly intensive AI
algorithms, like k-means clustering.
Peter.
Ruby Me wrote:
Why people say that Ruby is a slow language?
Because they don’t understand the difference between a programming
language and a compiler.
jwm
2010/11/8 Jörg W Mittag [email protected]:
Ruby Me wrote:
Why people say that Ruby is a slow language?
Because they don’t understand the difference between a programming
language and a compiler.
or they don’t understand the difference between a programmer and a
programmer, 
Kind regards,
Zuer (祖儿)
On Mon, Nov 8, 2010 at 1:13 PM, Phillip G.
[email protected] wrote:
2010/11/7 Jörg W Mittag [email protected]:
Ruby Me wrote:
Why people say that Ruby is a slow language?
Because they don’t understand the difference between a programming
language and a compiler.Or because they are stuck in the “CPU time is expensive!” mindset.
Or simply because they are parroting what they heard years ago,
without taking the time to check for themselves.
Regards,
Ammar
2010/11/7 Jrg W Mittag [email protected]:
Ruby Me wrote:
Why people say that Ruby is a slow language?
Because they don’t understand the difference between a programming
language and a compiler.
Or because they are stuck in the “CPU time is expensive!” mindset. 
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
One could even say even 1.8 wasn’t that bad. Made a benchmark last
month
which had 1.8.7 as participant, and it shows ruby has some speed edge in
its
fast load time. If some would like to see the bench:
http://www.untilnil.com/2010/10/recursivefibbenchcontinued/
2010/11/8 Ammar A. [email protected]
2010/11/9 Oliver Schad
[email protected]:
The winner in speed is always compiled native code. So you have to know
your requirements.
I’m not so sure, but ruby is always slower than Java?
I have experienced with some java application which did be slow.
Many moons ago I started a thread that advocated writing it in C if
you wanted performance. There were several discenting opinions and I
set up a little trial to generate all possible latin squares,
http://en.wikipedia.org/wiki/Latin_square. People then submitted
implementations in languages of their choice and I ran and timed them
on the hardware I had. The result was that ocaml beat out the field
including hand written C++ and Java, if I recall correctly erlang came
a close second followed by java.
It does mean however that you need to write the whole of the
application in language X (where X is not C, C++ or Java) as bridging
ocaml / erlang / haskell to ruby may well negate any advantages. But
how important is performance? If it is really really really important
then you would do well to look into ocaml or erlang.
However if you need to interface efficiently to ruby then C and C++
are a good bet. With jruby you get to access java. The difference
between first (ocaml) and third (java) was minimal. A different
problem may have reordered the top three but I suspect that they would
still be close.
This was all 1.8.* if I recall so I’m not sure how 1.9 would place.
But then again Jruby has been improving all the time.
If you must use ruby but need to speed some part of it up then ruby
and a library written in C is one option, jruby and the critical part
in java is the other.
I would recommend seeing if you can use jruby and then look to code
the critical parts in java. It is easier to become competent in Java
than it is to become competent in C / C++.
Learnt erlang as a result of that post
On Tue, Nov 9, 2010 at 1:10 PM, Oliver Schad
[email protected] wrote:
The winner in speed is always compiled native code. So you have to know
your requirements.
This may sound facetious, but it isn’t:
The fastest code is code that never runs.
In a nutshell, write your code well, and keep DRY and YAGNI close to
your heart.
That also means that you should keep around results of calculations
that take a long time around, and try to avoid hitting high-latency
bits and pieces whenever you can (“Do I really need an accurate
time? Then why am I accessing an NTP server, anyway?”).
Architecture wins, especially if you keep in mind the constrains of
your target system (I wouldn’t, ever, use Ruby, Java, or .NET to
program a micro-controller. Conversely, I wouldn’t write a CRUD
desktop app in C/C++ these days).
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
Ruby Me wrote:
Why people say that Ruby is a slow language? And is there any plans to
make it perfrom better in the near future? I was trying to start
learning it and someone told me it is slow and I really look for
something with high performance.
All interpreted languages are slow, because you need CPU cycles to
interpret instead doing the job. The only important question is: is it
fast enough for your use case? That’s an question which nobody can
answer for you.
You can mix most interpreted languages with native libs so you can split
the thing. And if it’s still too slow you should use only something like
C or C++.
And there are some tradeoffs you can make: Native speed with long and
unflexible code (C/C++) vs. optimizing your whole system (caching,
avoiding execution of code) and flexible short code.
The winner in speed is always compiled native code. So you have to know
your requirements.
Regards
Oli
On Tue, Nov 09, 2010 at 11:26:18PM +0900, Peter H. wrote:
Many moons ago I started a thread that advocated writing it in C if
you wanted performance. There were several discenting opinions and I
set up a little trial to generate all possible latin squares,
http://en.wikipedia.org/wiki/Latin_square. People then submitted
implementations in languages of their choice and I ran and timed them
on the hardware I had. The result was that ocaml beat out the field
including hand written C++ and Java, if I recall correctly erlang came
a close second followed by java.
C and C++ are not the same language, and there is typically a notable
difference in performance between code written in one and code written
in
the other, even when they do roughly the same thing. I’m sure C would,
at least in most cases, do at least as well as OCaml – even if C++
typically lands somewhere behind imperative OCaml code.
I’m not saying that you’re wrong about OCaml being a good choice for
speed. It usefully combines great performance with a good, friendly
syntax and powerful semantic model. I just don’t think it’s useful to
say OCaml comes in first while you mention C just because OCaml did
better than C++, which does not have the same performance
characteristics as C, in the general case.
Note that I’m referring to language names, but my observations tend to
hold true across major implementations of those languages, from what I
have seen.