Performance Ruby

[Goel]

Hi,

Is there any benchmark of the performance of Ruby vs. C, C++, Java etc?

I couln't find it on the ruby website.

Regards

 

[Robert Klemme]

Hi,

Is there any benchmark of the performance of Ruby vs. C, C++, Java
etc?

I couln't find it on the ruby website.

Regards

Yes, there are some public performance shootouts on the web. I'm sorry, I
don't have a URL handy.

Kind regards

robert

 

[Brian Schröder]

Hi,
=20
Is there any benchmark of the performance of Ruby vs. C, C++, Java etc?
=20
I couln't find it on the ruby website.
=20
Regards

You could start reading with this thread

http://groups-beta.google.com/group/comp.lang.ruby/browse_frm/thread/b4232a=
d4e01ed3ef/fd98604d40d7a6f3?lnk=3Dst&q=3Dbenchmark+comp.lang.ruby&rnum=3D23=
&hl=3Den#fd98604d40d7a6f3

theres a lot about this in the archives. It boils down to ten simple
commandments and one addition:

1.) Optimize only when it is really too slow.
2.) Only optimize if it is too slow
3.) Only optimize if it is too slow
4.) Only optimize if it is too slow
5.) Only optimize if it is too slow
6.) Optimize first by using a better algorithm.
7.) Only optimize if it is too slow
8.) If it really really is too slow rewrite the slow parts in C.
9.) Only optimize if it is too slow
10.) Only optimize if it is too slow

((11)) A lot of people think that the Alioth Benchmarks are crap.

regards,

Brian

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

 

[Lothar Scholz]

Hello Goel,

G> Hi,

G> Is there any benchmark of the performance of Ruby vs. C, C++, Java etc?

This makes no sense at all.
Ruby in another kind of tool then C,C++,Java.

If you want compare it with other languages then compare it with
Python,Perl or TCL.

If you don't understand why you can't compare it with a static typed
compiled language start writing programs in ruby for one month and
then think again.

 

[Goel]

I'm sorry, but my knowledge is not that deep.

I'm still from the 'old' Pascal school, learned some Java, understand OO and
the concept is very logic, however Java itself is for me 'too strange'.
When I saw some written code in Ruby, I immediately knew this was my
language, since the writing and logic is my naturally (for me at least).

A friend is thinking to use it at his work too (standalone), but must know
some things about the performance before he is going to use it; hence my
(wrong) question.

Regards, Goel

 

[Robert Klemme]

I'm sorry, but my knowledge is not that deep.

I'm still from the 'old' Pascal school, learned some Java, understand
OO and the concept is very logic, however Java itself is for me 'too
strange'. When I saw some written code in Ruby, I immediately knew
this was my language, since the writing and logic is my naturally
(for me at least).

A friend is thinking to use it at his work too (standalone), but must
know some things about the performance before he is going to use it;
hence my (wrong) question.

Performance is not everything. Maybe it helps to know which kinds of
problems your friend is going to solve with the language he chooses.

Kind regards

robert

 

[Gene Tani]

Robert K is correct. Some observes:

- many apps are bound by external constraints: your DB / web / FTP /
NFS server only runs so fast, i.e. C++ apps may be 0.3% faster in this
case.

- the development cycle in ruby is different from C/JAva. There isn't
compile-time checking the way a C++ /java programmer thinks about it.
You have to set up a meaningful Exception hierarchy and unit-test
extensively.

- after you profile a ruby app, you can choose to re-code part or all
of bottlenecks in C (rubyInline, ruby2C, maybe other tools out there)

 

[Lothar Scholz]

Hello Goel,

G> A friend is thinking to use it at his work too (standalone), but must know
G> some things about the performance before he is going to use it; hence my
G> (wrong) question.

So the answer is it maybe 200 times slower (for example a pure ruby
implementation of zip/gzip) or it might be only 5 times slower as C
when you call a lot of C buildin's or a C library wrapper.

Does this really help ? I guess not.

 

[Jeff Wood]

There is an online comparison of MANY computer languages ...

http://shootout.alioth.debian.org/

... there are some programs that don't seem to have any ruby solution
yet... if any of you feel up to it, ( or if you want to look at the
existing solutions that are there and performance tweak them ) ... It
would be a "good thing"

Anyways, I hope that provides the informatoin that the original post
was looking for.

j.

Hello Goel,
=20
G> A friend is thinking to use it at his work too (standalone), but must = know
G> some things about the performance before he is going to use it; hence = my
G> (wrong) question.
=20
So the answer is it maybe 200 times slower (for example a pure ruby
implementation of zip/gzip) or it might be only 5 times slower as C
when you call a lot of C buildin's or a C library wrapper.
=20
Does this really help ? I guess not.
=20
--
Best regards, emailto: scholz at scriptolutions d= ot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
=20
=20
=20
=20

--=20
"So long, and thanks for all the fish"

Jeff Wood

 

[Marek Kubica]

Hello!

There is an online comparison of MANY computer languages ...

http://shootout.alioth.debian.org/

.. there are some programs that don't seem to have any ruby solution
yet... if any of you feel up to it, ( or if you want to look at the
existing solutions that are there and performance tweak them ) ... It
would be a "good thing"

Heres another version of that shootout
http://dada.perl.it/shootout/

Brian Schröder put it imho right:
"Only optimize if it is too slow"

greets,
Marek

 

[Jeff Wood]

Only problem with that one is that it is SO old it's using ruby 1.6.7

j.

Hello!
=20
On Fri, 12 Aug 2005 01:04:31 +0900 Jeff Wood wrote:
=20
=20
Heres another version of that shootout
http://dada.perl.it/shootout/
=20
Brian Schr=F6der put it imho right:
"Only optimize if it is too slow"
=20
greets,
Marek
=20
=20
=20

--=20
"So long, and thanks for all the fish"

Jeff Wood

 

[Austin Ziegler]

There is an online comparison of MANY computer languages ...
=20
http://shootout.alioth.debian.org/
=20
... there are some programs that don't seem to have any ruby solution
yet... if any of you feel up to it, ( or if you want to look at the
existing solutions that are there and performance tweak them ) ... It
would be a "good thing"
=20
Anyways, I hope that provides the informatoin that the original post
was looking for.

The best option for this shootout is to NOT implement anything for it.

The people running it don't know the first thing about what they're
doing and won't take responsibility for the errors in methodology and
the fact that their presentation encourages bad interpretation. The
Alioth shootout is dishonest to its core.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Mark Probert]

Hi ..

A friend is thinking to use it at his work too (standalone), but must know
some things about the performance before he is going to use it; hence my
(wrong) question.

Perceived performance is a strange issue.

My experience has been that Ruby is "fast enough" for all that I want it
to do, including some fairly complex data collection and processing.
Any issues that I have had aren't with its "performance".

Now, if pure speed is what your friend is after, then it is going to
depend on the problem domain and finding the right tool for the job.
Though the real answer is going to lie in some compromise between
developer performance and system performance.

For example, J (www.jsoftware.com) is wonderful, fast, extra-ordinary in
its domain. Nothing can touch it, really. And the learning curve is
almost perpendicular. I have often wanted to us it in anger and could
not justify it. On the other hand, I can and do use Forth. Ruby won't
work there ;-) and I find it better than C.

So, the short answer is get your friend to try out Ruby. Post to clr if
there are problems and see for himself. If ruby is too slow, try
Python. Or OCaml. Or Nice.

Regards,

 

[BearItAll]

I'm sorry, but my knowledge is not that deep.

I'm still from the 'old' Pascal school, learned some Java, understand OO and
the concept is very logic, however Java itself is for me 'too strange'.
When I saw some written code in Ruby, I immediately knew this was my
language, since the writing and logic is my naturally (for me at least).

A friend is thinking to use it at his work too (standalone), but must know
some things about the performance before he is going to use it; hence my
(wrong) question.

When I first tried Ruby, my main software language was c++ and main script
language was perl or python. I decided that despite it being incredibly
easy to learn, Ruby was just too slow for the script project I was doing
at the time, which was a replacement for my server mirror software. The
speed of traversing through the directories increased my over night mirror
by a very long time (no point in saying how long because it obviously
depends on how many files are involved, but it was a great deal longer
than the previous version written in C++).

But I have since sort of slipped into using Ruby for just about all of my
scripting in such a way that I hardly noticed until I wrote this post,
that I haven't actually written in python since xmas. All those small two
minute jobs that you tend to need a lot, such as find routines and
maintenance tasks, are written in moments using Ruby.

I still find some areas of Ruby very confusing, compared to c++, but that
is more because I was C++ only so such a long time that I would of found
difficulty with any language.

Ruby rails is to me the biggee though. When it comes to web type work I
have always had a blind spot. I hated html from the day I first saw it,
and we've never got on since. So anything that can help me write a
web site without too much html involved is a good thing. It is a struggle
at the moment to find hosts for it, in fact I haven't found one yet, but
it is such a good web development environment that I am sure it will pick
up steam.

 

[Austin Ziegler]

There's the Great Computer Language Shootout.
<URL:http://shootout.alioth.debian.org/>

Which, as I keep reminding people, isn't worth the paper it isn't
printed on. It's a waste of time, effort, and credibility to keep
promoting it as if the people who created it know what they're doing.

Not all benchmarks are bad, but the GCLS is the least useful.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Brian Wisti]

=20
Which, as I keep reminding people, isn't worth the paper it isn't
printed on. It's a waste of time, effort, and credibility to keep
promoting it as if the people who created it know what they're doing.
=20
Not all benchmarks are bad, but the GCLS is the least useful.

I always had the impression that the GCLS was presented as "purely for
entertainment purposes only," and people who take them too seriously
were to be scoffed at by sane people everywhere as well as the
founders of the project.

That's just my perception, but this is one of the few cases where I
don't really care whether or my perception is correct.

Kind Regards,

Brian Wisti
http://coolnamehere.com/

 

[Austin Ziegler]

I always had the impression that the GCLS was presented as "purely for
entertainment purposes only," and people who take them too seriously
were to be scoffed at by sane people everywhere as well as the
founders of the project.
=20
That's just my perception, but this is one of the few cases where I
don't really care whether or my perception is correct.

Okay, to be completely fair: yes, the GCLS is presented as "purely for
entertainment purposes only." At least that's what is said on the GCLS
website, which makes it the operating theory, at least.

In practice, though, the Alioth shootout is heavily promoted by the
people what run it and others, and there are comparisons between
different languages and little is done to make sure that the various
languages don't cheat (I found a cheat in the Perl implementation of the
Ackermann and a sort-of-cheat in the Python implementation). There's a
whole veneer of respectability about this particular set of tests,
complete with the encouragement to "make your language perform better."
In other words, for something that's "for entertainment purposes only,"
there's a lot of time spent making it look "legitimate."

When the people who run it are confronted with this, they fall back on
the "it's not serious" line ... while very shortly after doing something
that suggests that it is, indeed, serious.

The Alioth shootout is dishonest in its presentation and purpose. It
does *more* than place "performance" numbers on the screen; it offers an
interpretation of those numbers ... all the while pretending not to
offer said interpretation.

Real world performance numbers are more useful, and when Ara Howard
tells me that Ruby performs fast enough for his image crunching, or Rich
Kilmer tells me that Ruby made Cougaar possible and fast, then I believe
them. These people (and others) are pushing Ruby further than anyone
else, including people who use Ruby on Rails. And yet, I also believe
DHH when he says that Rails scalability isn't a big issue, in that it
scales the same way that web applications have scaled for a while, and
the same way that Kuro5hin and Slashdot scaled -- more machines with
load balancing and separating the database server from the application
server.

If you want to see an *intense* Ruby application, look at my own
PDF::Writer. The layout engine is about as computationally intensive as
one will get in pure Ruby, and would merit dropping to C in some places
(except that I have deliberately made it a goal to keep the code pure
Ruby). On my VERY SLOW LAPTOP, it takes no more than ten minutes to
generate the 90+ page manual. It takes a matter of seconds to generate
each demo (and most of *that* is in the startup).

On my 3Ghz work machine, it's about 2 1/2 - 3 minutes to do the same
manual. I suspect that with the report generator that's being talked
about, there will be some time involved with the PDF generation for
output, but it will still be fast enough to be usable from Rails.

I'm getting ready to add SVG support to PDF::Writer, and my current code
is whipping through complex SVGs pretty quickly. For some things, it
takes enough processing time that I'll recommend people do partial
rendering beforehand -- which is a good idea in any case for many
things and not just for performance reasons. I'll be documenting the
technique, too.

I'm not saying anything new here, not really.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Ara.T.Howard]

Real world performance numbers are more useful, and when Ara Howard tells me
that Ruby performs fast enough for his image crunching, or Rich Kilmer tells
me that Ruby made Cougaar possible and fast, then I believe them. These
people (and others) are pushing Ruby further than anyone else, including
people who use Ruby on Rails. And yet, I also believe DHH when he says that
Rails scalability isn't a big issue, in that it scales the same way that web
applications have scaled for a while, and the same way that Kuro5hin and
Slashdot scaled -- more machines with load balancing and separating the
database server from the application server.

<snip>

here's some food for thought:

the other day my co-worker was out in dc. one of our clients wanted to gain a
better understanding of one of our products. the product in question is a
'fires' product that we make using nighttime lights of the world, some temp
info, etc. to show where nighttime fires are. the fires are placed into a
geographic grid - an image where each pixel maps to a lat/lon. the images are
quite simple and all meta info is in a .hdr file (this is envi's file format).
in any case placing fires in a grid leaves some empty grid cells since the
grid is of coarser resolution than the data. we fill this grid in using
nearest-neighbor. the client wanted to no which pixels were 'nubs' or centers
- which ones were actual pixels and not a product of filling. it turns out we
track this info, along with 15 bits of other stuff, in a 'flag' image - it's
simply an image of pixels where each pixel is a bitmask marking certain
attributes of each pixel as true or false such as 'cloudy' and the like.

so i needed to make a 'fire center' image - it would be just like a fire image
but contain only 'nubs' or centers. this is an easy thing to do since all i
had to do was copy the fires image and set everything to background that was
NOT a nub and was not no data (missing pixels). here's a sample run:

jib:~/eg/ruby/fires2firecenters/fires2firecenters-0.0.0 > time fires2firecenters F1420050720.0.fires

real 0m9.931s
user 0m2.240s
sys 0m4.580s

o.k. ten seconds. but what does that mean?

jib:~/eg/ruby/fires2firecenters/fires2firecenters-0.0.0 > ls -ltarh
F1420050720.0.fires F1420050720.0.flag F1420050720.0.fires.centers
-rw-rw-r-- 1 ahoward ahoward 102M Aug 12 17:42 F1420050720.0.fires
-rw-rw-r-- 1 ahoward ahoward 204M Aug 12 17:43 F1420050720.0.flag
-rw-rw-r-- 1 ahoward ahoward 102M Aug 12 17:44 F1420050720.0.fires.centers

so you can see both input images (fires, flag) are 100/200 mb respectively and
the output is 100 mb. so that's 300mb of io - at least. i didn't even bother
to profile the code because i was super busy that day and it was fast enough.
the really good part, however, is the code:

#!/usr/bin/env ruby
require 'narray'
require 'fileutils'
#
# parse command line - setup
#
fires_grid, flag_grid, fire_centers_grid = ARGV

unless fires_grid
STDERR.puts "#{ File::basename $0 } fires_grid [flag_grid] [fire_centers_grid]"
exit 1
end

flag_grid ||= fires_grid.gsub( %r/fires$/, 'flag' )
fire_centers_grid ||= fires_grid.gsub( %r/fires$/, 'fires.centers' )

center_mask = 2 ** (center_bit = 4)
no_data_mask = 2 ** (no_data_bit = 15)
#
# load files
#
fires = NArray::to_na( IO::read( fires_grid ), NArray::BYTE )
flags = NArray::to_na( IO::read( flag_grid ), NArray::SINT )
#
# zero out anything that's neither center nor no_data
#
fire_centers = fires
is_data = ( flags & no_data_mask ).not
is_not_center = ( flags & center_mask ).not
fire_centers[ is_not_center.and( is_data ) ] = 0
#
# write centers output
#
open(fire_centers_grid, 'wb'){|f| f.write fire_centers.to_s}
#
# copy .fires hdr to .fires.centers.hdr
#
FileUtils::cp "#{ fires_grid }.hdr", "#{ fire_centers_grid }.hdr"


it's a hack, it uses extensions, and it took me 5 minutes to write and ran
perfectly the first time. i love it.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[Gerardo Santana Gómez Garrido]

On Thu, 11 Aug 2005 14:12:47 +0200, Goel wrote:
=20

 

[Stefan Schmiedl]

Okay, to be completely fair: yes, the GCLS is presented as "purely for
entertainment purposes only." At least that's what is said on the GCLS
website, which makes it the operating theory, at least.

If I'm into programming mood on the few days I'm not busy programming,
I try my hand at coding shootout tasks. Then I try to learn from the
differences between my solution and the one published on the site.

I'm not much of a shootout person myself.

s.