Citation needed. Both CPython and MRI are slow - if you need computational speed, use something else. But when your are comparing them to each other, CPython is faster. I don't know where you are getting that significantly faster bit from.

Since most benchmarks are unscientific, this one is as good as any. So here goes:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.

Since benchmarks are completely worthless, let's just stop this pissing match right now.

> I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.

Citation needed again. Ruby 1.9 is slower than Python 3, and Python 3 is slower or as fast as Python 2 on Python official benchmarks.

http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...

> Since benchmarks are completely worthless, let's just stop this pissing match right now.

Benchmarks are far from worthless. And pissing match? Asking for citations amounts to pissing match? The parent claimed something that isn't true(ruby 1.9 significantly faster than CPython - that has never been the case). And you are adding python 2.x was slower than 1.9, when 2.x is generally faster than 3.

I love ruby as much as the next guy. But when it comes to execution speed, ruby has always been the slowest among ruby, python, and perl.

Fib(36)

Python 2.7.2

    def fib(n):
        if n == 0 or n == 1:
           return n
        else:
           return fib(n-1) + fib(n-2)
     
     for i in range(36):
         print "n=%d => %d" % (i, fib(i))'

python -c 20.69s user 0.06s system 99% cpu 20.807 total

Ruby 1.9.3 def fib(n) if n == 0 || n == 1 n else fib(n-1) + fib(n-2) end end

    36.times do |i|
      puts "n=#{i} => #{fib(i)}"
    end

ruby 11.44s user 0.03s system 99% cpu 11.507 total

I guess since benchmarks are not completely worthless, we should conclude that ubuntu doesn't keep up on ruby and uses 2-3 year old versions.

I wasn't accusing you of starting the pissing match.

> I guess since benchmarks are not completely worthless,

The original keeps getting re-iterated: http://programmingzen.com/2007/11/28/holy-shmoly-ruby-19-smo...

The original author, on a basis of a fib benchmark, concludes ruby 1.9 is faster - that is as flawed as it gets.

Did you try running with Python 3? You will get around the same time as you get with Python 2.7. Pick anything from here http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... and run it with Python 2.7 and ruby 1.9. The programs which are faster with Python 3 will be mostly faster with Python 2.7. 2.7 isn't slower than ruby 1.9; it is faster in most of the cases.

Regarding the fib example, when the original was doing the rounds, I didn't find any explanations from python or ruby implementors. I can't say why, but most likely python has a higher overhead with growing call stacks, and ruby does some optimizations.

Data is not dishonest and benchmarks are not dishonest. What is dishonest is this tendency to cherry-pick only the case which is convenient to you, as you have done here. If you want to talk about Ruby performance vs. Python then you will have to dig into something like the site linked previously, which has many different benchmarks run on a uniform testbed rather than a single cherry-picked case run in whatever way you felt like.

>>ubuntu doesn't keep up on ruby and uses 2-3 year old versions<<

Huh? Since 21 Apr 2012, the benchmarks game has shown - ruby 1.9.3p194 (2012-04-20 revision 35410).

If you're looking at measurements made on the quad core machine, then remember to check the "≈ CPU Load" column to see whether some programs are using multiple cores and some programs are only using one core.

When the comparison would be better without that complication, look at single core measurements -- http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

>>Since most benchmarks are unscientific, this one is as good as any.<<

1) You seem to be using "unscientific" as a nothing more than an insult.

2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".

3) If your conclusion was correct then that wouldn't mean that the benchmark was good, just that it was also bad.

>>Since most benchmarks are unscientific, this one is as good as any.<<

>1) You seem to be using "unscientific" as a nothing more than an insult.

More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless".

> 2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".

IMO shootout benchmarks are better than random benchmarks on the web as they detail the testing environment, provide the source code and can be re-created

>>More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless"<<

It's a dirty job but it still has to be done ;-)

Let them reply and then answer them.