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.
--
Posted via http://www.ruby-forum.com/.
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
mediocre*interpreter 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!
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 Wed, Nov 3, 2010 at 12:54 PM, Ruby Me <i_baseet@hotmail.com> wrote:
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.
--
Posted via http://www.ruby-forum.com/\.
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.
--
The biggest problem with communication is the illusion that it has occurred.
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.
--
Posted via http://www.ruby-forum.com/.
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
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
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
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.
On Nov 3, 4:11 pm, Steve Klabnik <st...@steveklabnik.com> 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.
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...
On Nov 3, 5:04 pm, Josh Cheek <josh.ch...@gmail.com> wrote:
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...
Another nice thing about JRuby is it gives you access to Java. And it's
easy, and it still feels like Ruby.
On Wed, Nov 3, 2010 at 8:43 PM, Peter Lane <peter.c.r.lane@googlemail.com>wrote:
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.
--
Posted via http://www.ruby-forum.com/\.
or they don't understand the difference between a programmer and a
programmer, 
Kind regards,
Zuer (祖儿)
2010/11/8 Jörg W Mittag <JoergWMittag+Ruby@googlemail.com>:
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. 
2010/11/7 Jörg W Mittag <JoergWMittag+Ruby@googlemail.com>:
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.
--
Phillip Gawlowski
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.
I'm not so sure, but ruby is always slower than Java?
I have experienced with some java application which did be slow.
2010/11/9 Oliver Schad <spam.entfernen.und.bring.gefaelligst.ein.bier.mit@oschad.de>:
The winner in speed is always compiled native code. So you have to know
your requirements.
--
Kind regards,
Zuer (祖儿)
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).
On Tue, Nov 9, 2010 at 1:10 PM, Oliver Schad <spam.entfernen.und.bring.gefaelligst.ein.bier.mit@oschad.de> wrote:
The winner in speed is always compiled native code. So you have to know
your requirements.
--
Phillip Gawlowski
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.
It's quite possible that something has changed recently that I'm not aware
of.
Or simply because they are parroting what they heard years ago,
without taking the time to check for themselves.
Regards,
Ammar
On Mon, Nov 8, 2010 at 1:13 PM, Phillip Gawlowski <cmdjackryan@googlemail.com> wrote:
2010/11/7 Jörg W Mittag <JoergWMittag+Ruby@googlemail.com>:
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.
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 
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 Ali <ammarabuali@gmail.com>
On Mon, Nov 8, 2010 at 1:13 PM, Phillip Gawlowski > <cmdjackryan@googlemail.com> wrote:
> 2010/11/7 Jörg W Mittag <JoergWMittag+Ruby@googlemail.com<JoergWMittag%2BRuby@googlemail.com>
>:
>> 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
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.
On Tue, Nov 09, 2010 at 11:26:18PM +0900, Peter Hickman 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.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]