This might be a stupid question, but I really wonder if ruby is much
slower than python and perl.
It could be very slow, if you set out to make it so. Othervise, they
are comparable in speed.
http://shootout.alioth.debian.org/
Konstantin Levinski wrote:
It could be very slow, if you set out to make it so. Othervise, they
are comparable in speed.
http://shootout.alioth.debian.org/
Perl & Ruby
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=perl&lang2=ruby
Python & Ruby
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=ruby
Psyco & Ruby
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=psyco&lang2=yarv
On 3/31/06, [email protected] [email protected] wrote:
This might be a stupid question, but I really wonder if ruby is much
slower than python and perl.
Try it. And ignore anyone who tells you to look at the utterly useless
Alioth shootout. It doesn’t model anything real-world and doesn’t
actually tell you anything about performance for your problems.
I haven’t checked in a while, but they weren’t very honest about their
aims last time I checked, either. It’s simply a matter of
self-promotion and comparison for Inane Gullibles.
-austin
Austin Z. wrote:
self-promotion and comparison for Inane Gullibles.
-austin
Austin Z. * [email protected]
* Alternate: [email protected]
“I haven’t checked in a while…”
Then your comments would apply to the Alioth shootout in… 2004?
There’s nothing wrong with saying how little can be learned from
measuring small programs, but saying don’t look suggests there’s
something to be hidden.
Austin Z. wrote:
aims last time I checked, either. It’s simply a matter of
Austin Z. * [email protected]
* Alternate: [email protected]
And you believe all that without even looking - truly remarkable!
(I suppose there are people who make judgements about Ruby without
looking.)
On 4/4/06, Isaac G. [email protected] wrote:
self-promotion and comparison for Inane Gullibles.
“I haven’t checked in a while…”
Then your comments would apply to the Alioth shootout in… 2004?
- I avoid the shootout like the plague, until you pop up and
pretend that your pet project has any relevance to anything.
There’s nothing wrong with saying how little can be learned from
measuring small programs, but saying don’t look suggests there’s
something to be hidden.
No, saying “don’t look” says that your aims are bogus, your tests are
worse, your validation is nonsensical to nonexistent, and your
presentation is dishonest.
Saying “don’t look” says that the Alioth shootout isn’t worth the
server space it takes up. It’s certainly not worth the amount of
pimping you do for it.
-austin
On 4/4/06, Isaac G. [email protected] wrote:
And you believe all that without even looking - truly remarkable!
(I suppose there are people who make judgements about Ruby without
looking.)
Isaac,
I see you’re as bad at reading as ever. I didn’t say that I haven’t
looked. You know better than that. I haven’t looked recently. After the
initial round of accurate criticism (with evidence) that I unleashed on
you well over a year ago, I checked the next time you pimped your
worthless nonsense (about three months later).
You hadn’t fixed a single damned thing.
And the next time (again, about three months later)? You still hadn’t
fixed a single damned thing.
Obviously, over time, you have exhibited an interest in pimping your
shootout, but not fixing your methodology or presentation.
The issues with the Alioth shootout cannot be fixed cosmetically.
There’s something rotten at the core of this project that suggests it
should be cut loose and repudiated by anyone who has ever supported it.
You’re as capable as I am at digging in the archives for my previous
criticisms. Show me that you’ve fixed the core problems, not just put
makeup on a pig’s arse and called it beautiful.
-austin
On 4/4/06, Isaac G. [email protected] wrote:
And you believe all that without even looking - truly remarkable!
(I suppose there are people who make judgements about Ruby without
looking.)
Can we avoid this shootout thing again. Anyone interested in the
history of this thread can find plenty on the archive, we don’t need
to rehash it.
That having been said, comparing speed is a tough job. I’ll
re-iterate the standard advice which seems to work to the OP. Try
just writing whatever you want in ruby first… then if you find
bottle necks, try to optimize them, and if you can’t, C extensions are
always an option for the really computation heavy stuff. I’m not sure
i’ve seen anyone switch to perl or python because of speed, because
the gain is going to be something small if anything.
So… worry about performance when it becomes an issue. Or… if you
know how to optimize perl or python to make it sing, maybe go ahead
and use them. Otherwise, I’m pretty sure you’ll find that speed
hangups can be avoided when needed in Ruby.
On 4/4/06, Isaac G. [email protected] wrote:
useless
- I avoid the shootout like the plague, until you pop up and
Saying “don’t look” says that the Alioth shootout isn’t worth the
(I suppose there are people who make judgements about Ruby without
looking.)
I’ve looked at your site, nearly every time you’ve come in posting
specific
benchmarks about something or other. I think its current incarnation is
by
far the worst. You use certain performance and code characteristics,
but
instead of quantifying the actual values in the comparisons (only in the
individual listings) you list them as, X is Y times better/worse than Z.
That tells me next to nothing. 1.1 times faster means very little at
10ms,
but quite a lot at 1hr. While I don’t always agree with Austin’s
attitude
towards this subject, I do agree that the site is rarely useful, and
often
causes people to mis-represent a given statistic.
On 4/4/06, Isaac G. [email protected] wrote:
useless
- I avoid the shootout like the plague, until you pop up and
Saying “don’t look” says that the Alioth shootout isn’t worth the
(I suppose there are people who make judgements about Ruby without
looking.)I understand that you are upset, but I had a look and I think I have
enough reason to consider the shootout irrelevant:
First, everybody can contribute ones program, like that, so what if I
want
ruby to look bad, well easy enough, there comes one example into mind
(c.f.
http://shootout.alioth.debian.org/debian/benchmark.php?test=binarytrees&lang=ruby),
the program does not even run.
Second I have often seen ruby1.9 being used, futile ( so I have my two
favorite words together “futile” and “irrelevant”
to explain that 1.9 is not to be used for such a thing.
I checked a different program, sorry cannot give you the link, from the
shootout, it was written for slow performance period.
And last but not least, performance rarely matters and when it really
matters you need a change of magnitude.
And for that to accomplish you have to extend ruby in C or interface
with C,
which is pretty easy compared to python or - even worse - perl.
So I honestly understand why Austin is upset although, I agree with you,
scientifcly speaking his attitude is wrong.
But I believe his conclusions are correct nontheless.
Cheers
Robert
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
- Albert Einstein
Tanner B. wrote:
Try it. And ignore anyone who tells you to look at the utterly
but quite a lot at 1hr.
On that page ( http://shootout.alioth.debian.org/gp4/ruby.php ) the
first paragraph includes a link to the “CPU time and Memory use
measurements”
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&lang2=ruby
While I don’t always agree with Austin’s attitude
towards this subject, I do agree that the site is rarely useful, and often
causes people to mis-represent a given statistic.
I also hear positive comments.
Robert D. wrote:
Try it. And ignore anyone who tells you to look at the utterly
(I suppose there are people who make judgements about Ruby without
looking.)I understand that you are upset, but I had a look and I think I have
enough reason to consider the shootout irrelevant:
First, everybody can contribute ones program, like that, so what if I want
ruby to look bad, well easy enough,
Until someone who wants to make Ruby look good contributes a better
program 
there comes one example into mind (c.f.
http://shootout.alioth.debian.org/debian/benchmark.php?test=binarytrees&lang=ruby),
the program does not even run.
Thank you, I can see that program has been measured with too short a
timeout.
The same program is shown here
http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=ruby&id=0
Second I have often seen ruby1.9 being used, futile ( so I have my two
favorite words together “futile” and “irrelevant”
to explain that 1.9 is not to be used for such a thing.
The measurements on Gentoo : Intel are made for Ruby 1.8.4
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&lang2=ruby
I checked a different program, sorry cannot give you the link, from the
shootout, it was written for slow performance period.
Standard answer: contribute better programs.
And last but not least, performance rarely matters and when it really
matters you need a change of magnitude.
And for that to accomplish you have to extend ruby in C or interface with C,
which is pretty easy compared to python or - even worse - perl.
http://shootout.alioth.debian.org/gp4/miscfile.php?file=benchmarking&title=Flawed%20Benchmarks
On 4/4/06, Robert D. [email protected] wrote:
I understand that you are upset, but I had a look and I think I have
enough reason to consider the shootout irrelevant: First, everybody
can contribute ones program, like that, so what if I want ruby to look
bad, well easy enough, there comes one example into mind […] the
program does not even run.
The better example is the Ackermann. On Unix, at least, the stack is
able to be reset with ulimit – and the Ruby run of Ackermann does not
use this, even though Ruby’s stack frame is known to be larger than most
other programming languages.
The Python implementation does some stack manipulation without which the
program won’t run at all (even with ulimit). One of the Perl
implementations is so compact as to be unreadable – and it’s done so
deliberately.
[…]
So I honestly understand why Austin is upset although, I agree with
you, scientifcly speaking his attitude is wrong. But I believe his
conclusions are correct nontheless.
Scientifically, my attitude toward the Alioth shootout is spot on. It’s
not only benchmarking (lies, damned lies and [statistics | benchmarks]),
but it’s completely dishonest benchmarking for the reasons that you’ve
indicated above, and (last I checked) the website claimed far more than
is possible, especially since there is no control factors or proper
statistical analysis.
-austin
On 4/4/06, Isaac G. [email protected] wrote:
While I don’t always agree with Austin’s attitude
towards this subject, I do agree that the site is rarely useful, and often
causes people to mis-represent a given statistic.I also hear positive comments.
On ruby-talk?
Seriously, it’s fine that you have this thing and maybe someone
finds it useful, but it doesn’t seem well recieved on it’s list and
the bottom line is it’s not very useful for answering the OP’s
question.
People have made their points loud and clear. Perhaps you should do
the kind thing and just let it go. If there is a community which
embraces your shootout, discuss it with them.
Hey, if it makes y’all feel any better, Ruby is still worlds faster than
JRuby (though we’re naturally working on that 
On 4/4/06, Isaac G. [email protected] wrote:
I checked a different program, sorry cannot give you the link, from the
shootout, it was written for slow performance period.Standard answer: contribute better programs.
Standard answer: don’t participate in this. There’s nothing honest
about it, and Isaac is essentially no better than a spammer since his
primary contribution to ruby-talk is to promote this site which
provides no value to anyone and, IMO, provides harm to anyone who
takes the site seriously.
-austin
Slower in what sense. It’s certainly not slower to develop with than
either of its scripting colleagues and I find it easier to read.
The real question these days is is the language fast enough. You have
to remember that processor power is 50 to 100 cheaper than manpower. I
can afford to waste several days of processor time if I can save an
hour of manpower.