

Ruby 2.0 speed ÷ Python 3 speed - ksec
http://benchmarksgame.alioth.debian.org/u32q/ruby.php
Yes i know that benchmarks mean fairly little, but Ruby here is WAY off the chart. Wasn't 2.0 suppose to improve on performance? And it is even worst then PHP.
======
ioquatix
I use Ruby ALL the time, and I've never once thought, "I wish this was
executing faster".

Yes, perhaps it could be more efficient, but I don't use Ruby for speed. The
way that I see it, Ruby exchanges execution time for programmer time.
Alternatively, If I want something to be fast, I'll spend a few days writing
it in C/C++/Assembler, but I'd expect to spend at least an order of magnitude
more time writing code.

~~~
uribs
Or you could use something like LuaJit, Node.js, Java or Scala that achieves
both goals.

~~~
the_french
None of those languages are equivalent to ruby. They may be faster but they
don't support the same features, syntax etc...

------
awj
Follow up: The Computer Language Benchmark Game still only marginally relevant
to real world use.

~~~
valdiorn
It's very relevant for some types of programs. For web development, unless
you're building the next Twitter, not so important...

...now if you're building a chess engine, that's a different story.

(I just take chess as an example as it's my latest hobby. It's the first and
only project where I found it necessary to switch to C because of performance
considerations (switched from C#).)

~~~
awj
For the various tasks involved in a chess engine Python and Ruby are likely to
either be performance equivalent (in that performance doesn't really matter)
or entirely unsuitable.

------
JonnieCache
Most applications still I/O bound.

Woes of developers who prefer complaining to extracting the CPU bound parts of
their app to another language still difficult to worry about.

~~~
coldtea
Why "extract parts to another language" in the first place, if the more
dynamic language has TONS of headroom to get faster?

------
psylence519
Speed still irrelevant in many applications.

~~~
pmelendez
I don't know about that.

Maybe is fine if you have a controlled traffic, but with better speed you can
manage more traffic with the same hardware. That's why Facebook had to build a
PHP compiler at some point.

~~~
chadrs
For probably almost every website/webapp in the world, the amount of servers
you have is 1. Facebook is not a typical application.

Besides, code is written for more than just websites. Chef/puppet/cfengine,
one-off scripts you write, etc. There's a whole lot of these types of things
that don't matter if your code takes 0.01 seconds or 0.05 seconds.

~~~
pmelendez
"For probably almost every website/webapp in the world, the amount of servers
you have is 1." Still if I can do the same thing in a cheaper server with the
same level of productivity, why wouldn't I do that?

"There's a whole lot of these types of things that don't matter if your code
takes 0.01 seconds or 0.05 seconds." Yeah but why would you prefer Ruby
instead of PHP/Python/Perl for those things then?

~~~
griffordson
Because they prefer Ruby? I personally wouldn't choose PHP or Perl unless I
had no other choice. Nothing wrong with other people choosing them, but they
aren't for me. And given the choice between Python and Ruby, I'll choose Ruby
unless there is a compelling reason not to. And saving a few hundred dollars
on a commodity server would never be compelling enough for me.

Edit: And when I actually _need_ better performance from a specific piece of
code, I can and do drop down to C.

------
jensnockert
I haven't taken a look at the actual programs, but given the nature of the
benchmarks the result can probably be interpreted as 'numpy is still quite
fast' also?

~~~
draegtun
I don't think Numpy is allowed or used in these benchmarks. However GMP is and
that's why _pidigits_ is so much slower on Ruby.

~~~
jamesjporter
Of course an advantage of python over ruby (speed-wise) is that you can
leverage numpy if you need to do fast matrix operations, whereas ruby has no
such library (that I'm aware of).

~~~
draegtun
And ditto for Perl: PDL - <http://pdl.perl.org>

However I think the basis of these benchmarks is really to pit languages
against each other and not it's frameworks/libraries.

------
nevinera
That's a pretty strong conclusion to draw from these results..

------
VeejayRampay
Ruby 2.0 was JUST released. It'll get faster, just like it happened for 1.8
and 1.9.

Python was released in what? 2008? 2009? I don't want to be that person, but
if we're going to compare language based on benchmarks that are pretty
irrelevant to modern uses already (like the CLBG is), at least let's pick
"equivalent" languages and let's try avoiding the obvious biases.

~~~
dscrd
>It'll get faster,

There's absolutely no reason to believe that's true.

~~~
VeejayRampay
JRuby is growing stronger and so is Rubinius. As those implementations grow
and mature, they'll get faster because they offer solutions in terms of
runtime that piggyback on technologies that are getting better and faster at
optimizing the bytecode produced (JVM, LLVM in that case).

I _do_ think Ruby will get faster eventually. Maybe not to the point that Ruby
suddenly becomes "fast" of course, but by a margin that can make a difference.
This is only my opinion (backed by some benchmarks in -for now- particular
circumstances) of course, but I'm hopeful that the situation will improve.

------
petercooper
Except their benchmarks are full of poo poo. The Python pidigits benchmark
uses a third party C extension for high performance math, whereas the Ruby 2.0
pidigits benchmark is pure Ruby.

Of course someone will lose a fight when their opponent is wearing a jetpack
and rocket powered shoes.

~~~
draegtun
Other languages in those _pidigits_ benchmarks (Perl, Lua, PHP, Racket, Lisp
SBCL and probably more) also use the GMP maths library. So there is nothing
stopping Ruby benchmarks also using it as well (just need to request relevant
Ruby GMP library are installed on the Alioth benchmark machines).

Anyway you didn't seem too fussed about what the Alioth benchmarks showed in
the past - <https://news.ycombinator.com/item?id=634738> :)

~~~
petercooper
Because someone can't change their opinion in 4 years..

I hadn't looked at the source code back then. Only now when this particular
variant of the benchmark shows some rather unrealistic results. Another
example (binary trees, I believe) has Ruby using a single process whereas the
Python example is using multiple processes to spread the load, so even though
Ruby wins on CPU time, Python wins with a slightly lower wall-clock time.

And making the Ruby pidigits benchmark use GMP too? That defeats the point of
benchmarking one language against another if you can just call out to C
libraries for everything (hey, there's an idea.. Ruby could be parallel with C
if we just did that). It should be pure language against pure language
otherwise it's totally meaningless (and, well, it is, as it stands).

~~~
igouy
What's preventing Ruby 2.0 from "using multiple processes to spread the load"?

>>if you can just call out to C libraries for everything<<

You can't just call out _for everything_.

There have been language implementations that used GMP under-the-covers, so -
to level the playing field - everyone can call out for GMP and PCRE.

~~~
petercooper
Nothing, it seems. But a benchmark is pointless if you aren't comparing like
for like, yet people are clearly taking the results as some sort of serious
indicator.

As it is, it's like sending two different cars around two different tracks and
comparing how long they took.

~~~
igouy
>>But a benchmark is pointless if you aren't comparing like for like<<

According to you it defeats the point when we do compare like to like -- "if
you can just call out to C libraries".

>>yet people are clearly taking the results as some sort of serious
indicator<<

Offer them something better.

>>sending two different cars around two different tracks<<

No. It's like saying here's the track - Ruby guy bring out your best cars,
Python guy bring out your best cars - and sending them around the same track.

The possible mismatch between programs written for quad-core and those written
for single-core is marked.

You can mention the difference between CPU time and wall-clock time because
both are intentionally shown, along with "CPU Load" so you can see how much
difference quad-core has made.

And as draegtun informed you, there's another set of measurements that removes
that difference by forcing all the programs onto a single core.

The problem with the Ruby binary-trees programs is that they run out of
memory.

[http://benchmarksgame.alioth.debian.org/u32q/program.php?tes...](http://benchmarksgame.alioth.debian.org/u32q/program.php?test=binarytrees&lang=yarv&id=2)

------
static_typed
Well, if it ran any faster all those Rails sites would get compromised even
quicker, so surely this is a good thing? Brogrammer security through
performance woes.

~~~
eric970
^ Excellent comment right here. +1 for educational value.

