Ruby Perofrmance

R

Ruby Me

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.
 
J

Josh Cheek

[Note: parts of this message were removed to make it a legal post.]

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.
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 :p (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!)
 
S

Shadowfirebird

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.
 
N

namekuseijin

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.
 
S

Steve Klabnik

[Note: parts of this message were removed to make it a legal post.]

It's quite possible that something has changed recently that I'm not aware
of.
 
N

namekuseijin

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...
 
N

namekuseijin

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

Peter Lane

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.
 
J

Josh Cheek

[Note: parts of this message were removed to make it a legal post.]

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.
Another nice thing about JRuby is it gives you access to Java. And it's
easy, and it still feels like Ruby.
 
J

Jörg W Mittag

Ruby said:
Why people say that Ruby is a slow language?

Because they don't understand the difference between a programming
language and a compiler.

jwm
 
Z

zuerrong

2010/11/8 J=C3=B6rg W Mittag said:
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,
=C2=A0 =C2=A0 =C2=A0Zuer (=E7=A5=96=E5=84=BF)
 
P

Phillip Gawlowski

2010/11/7 J=F6rg W Mittag said:
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. ;)

--=20
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.
 
A

Ammar Ali

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
 
O

Oliver Schad

Ruby said:
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
 
Z

zuerrong

2010/11/9 Oliver Schad
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.


--=20
Kind regards,
=C2=A0 =C2=A0 =C2=A0Zuer (=E7=A5=96=E5=84=BF)
 
P

Peter Hickman

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 :)
 
P

Phillip Gawlowski

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

Peter Hickman

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. =A0I'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 focused on C, and to some extent C++, as it is seen as a language
that gets closest to the metal short of assembler. In the old days the
only way to get the most performance out of some hardware was to write
it (or part of it) in C or assembler. Other languages just did not
come close.

These days however languages that such as ocaml, erlang and java have
got so good that the gap between C/C++ is less significant and
becoming a competent java programmer is much easier than becoming a
competent C programmer. That said you can get excellent performance
from these languages with less risk in development time and code
quality issues than going for C/C++.
I'm not saying that you're wrong about OCaml being a good choice for
speed. =A0It usefully combines great performance with a good, friendly
syntax and powerful semantic model. =A0I 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.

The biggest issue for me was that the gap between C/C++ and languages
like ocaml, erlang and java is getting to the point where we can no
longer say that C/C++ will be the fastest. I was a big proponent of
the "write it in C" school when it comes to performance, I found out
that other languages were significantly faster than I assumed. I still
prototype in Ruby, but I no longer automatically rewrite it in C.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,142
Messages
2,570,819
Members
47,367
Latest member
mahdiharooniir

Latest Threads

Top