Benoit Daloze wrote:
> 2010/2/23 Jrg W Mittag
> <JoergWMittag+Ruby / googlemail.com<JoergWMittag%2BRuby / googlemail.com>
>> Alexander Jesner wrote:
>>> On 02/22/2010 20:30, Benedikt Mller wrote:
>>>> Ruby is not the fastest interpreted language out there.
>>> If you have not already done so, switch to Ruby 1.9.
>> I have seen this claim that Ruby 1.9 is somehow faster than Ruby 1.8
>> repeated over and over again, but I have *never* seen any credible
>> evidence for that, neither in my own benchmarks nor in Antonio
>> Cangiano's (or any other, for that matter). Does anyone have any
>> evidence that this is actually the case? I would be very interested in
>> that.
> "I have *never* seen" Maybe you didn't look enough. Anyway, I think there
> are plenty of benchmarks ...
> 
> Test yourself and you'll see.

Did you even read the article you replied to? I already wrote that I
*did* my own tests and they I *did not* see any statistically
significant difference in performance.

> I think it's most of the time faster or equal in Ruby 1.9.

It's interesting that you use the word "think" here. So, apparently,
you have your (subconcious) doubts, too.

> There is a reason for this speed improvement, I let you search it.

Again, I would like to know. The *only* source I could find so far, is
a video from a BoF session with Jon Lam from maybe two years ago,
which goes something like this:

| Audience: What about 1.9 support?
| JL: Microsoft has commited to making IronRuby a *real* Ruby
|     Implementation that runs *real* Ruby code. Right now, *real* Ruby
|     code is written in Ruby 1.8. We would *love* to start with Ruby
|     1.9, because it has some semantic changes that make it much easier
|     to implement and much easier to implement *fast*. But we have to
|     stay with 1.8 for now.

[Don't hold me to the exact wording. This is all from memory, and it
was just a minor sidenote in a video I watched two years ago.]

This is pretty much the only source I could find which actually names
a *reason* for the claimed speed improvements. However, "some semantic
changes" isn't actually incredibly precise, after all, in a
programming language, pretty much *everything* is a "semantic change".

So, if you know the reason, please share it. Saying "I let you search
it" isn't exactly helpful. After all, I wouldn't have asked if I
hadn't searched first, that's Netiquette 101.

> You mention usual Antonio Cangiano Benchmarks:
> http://antoniocangiano.com/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal/
> 
> Well, there is a long time I keep traces of these benchmarks:
> 
> MBP => MacBookPro, 2x2.26GHz, 2Go
> 
> P => patchlevel
> R => revision
> T => trunk
> Time Computer OS 32/64bit RubyVersion
> 0.684  MBP  Mac  64  1.9.2  2010-01-14  T  26319
> 0.836  MBP  Lin  32  1.9.2  2009-07-18  T  24186
> 0.899  MBP  Mac  32  1.9.2  2009-11-04  T  25635
> 1.719  MBP  Win  32  1.9.2  2009-07-18
> 1.850  MBP  Mac  32  1.8.6  2008-08-11  P  287
> 2.000  MBP  Mac  32  1.8.7  2009-12-24  P  248
> 2.406  MBP  Win  32  1.9.1  2009-01-30  R  21907
> 2.937  MBP  Win  32  1.8.6  2007-09-24  P  111

Unfortunately, this table doesn't show the execution environment of
the individual benchmark runs. The only way in which this table is
useful, is if the benchmark runs were tightly controlled. Otherwise
you get uncontrolled variables, and all your benchmark results mean
squat.

In statistics, this is called "controlling your variables", but Zed
Shaw said it much better: "If you want to measure shit, don't measure
other shit."

In other words, if you want to measure Ruby 1.9 vs. Ruby 1.8, measure
Ruby 1.9 vs. Ruby 1.8 and not Ruby 1.9 and YARV vs. Ruby 1.8 and MRI,
because that way you will never know whether the performance
difference came from Ruby 1.9, YARV or a combination of the two.

> If that is not clear ...
> All 1.9.2 are faster(more than 2 times here). The only exception is probably
> due to better implementation of 1.8 on Mac than Windows (the 1.9.1 is
> probably an early version too).

Like I wrote above: *if* you actually *did* properly control your
variables for these benchmarks, then, yes, they show indeed a
performance increase for Ruby 1.9. And in that case, you really should
publish these results, because, like I wrote earlier, there is nothing
like this out there, at the moment.

jwm