Austin Ziegler wrote:
> On 10/30/06, Zed A. Shaw <zedshaw / zedshaw.com> wrote:
>> Well, that's kind of just Ruby on Windows for ya. My unofficial
>> experience (which everyone constantly blasts me for, so I'm obviously
>> wrong) is that Ruby on Win32 is about 1/10th the speed of Linux 2.6 on
>> the same computer. This is with the exact same non-rails Mongrel
>> handler tests I run. Cygwin is then about 1/2 the speed of that.
> 
> Zed, your wounded act is wearing thin, if it was ever amusing to begin
> with. It also doesn't come close to the truth (your claims about being
> blasted). Your numbers look suspicious to me, but I'm also not doing any
> performance testing on any of this stuff.

Ah, but I am. :) Zed's numbers are *very* suspicious. Here's what I
found with the One-Click Ruby, the CygWin Ruby, and a Gentoo-optimized
Ruby on a CPU-bound benchmark (which I've profiled and happens to spend
most of its time in the guts of the Ruby interpreter):

Native Windows One-Click Ruby Installer:
ruby 1.8.5 (2006-08-25) [i386-mswin32]
Matrix of dimension 256 times its inverse = identity? true
137.658000   0.060000 137.718000 (137.719000)

CygWin Ruby:
ruby 1.8.5 (2006-08-25) [i386-cygwin]
Matrix of dimension 256 times its inverse = identity? true
137.598000   0.110000 137.708000 (137.768000)

Gentoo Linux Ruby
Compiled from source with GCC 4.1.1 -O2 -march=athlon-xp
-fomit-frame-pointer
ruby 1.8.5 (2006-08-25) [i686-linux]
Matrix of dimension 256 times its inverse = identity? true
107.380000   0.010000 107.390000 (107.425632)

Note that the One-Click, compiled with an old Microsoft compiler (right,
Austin?) and the CygWin, compiled with gcc 3. something, are dead even.
CygWin is *not* half the speed of the One-Click! And it looks to me like
they were both compiled for i386!

Now the Linux Ruby is faster -- significantly so -- but not 10X. It's
not even 2X! I *know* how that was compiled, though. It used the latest
"stable" GCC, 4.1.1, -O2 optimization *and* the "march-athlon-xp" tuning
to the hardware! Somebody (please repost -- I've forgotten the details)
actually ran through compiler options on this benchmark and determined
that the biggest improvement in fact came from exactly that -- compiling
for the chip!

The bad news is, given a restriction to the i386 target, I'm not sure
any other compiler juggling is going to make a difference. I'm not
planning on recompiling my Linux Ruby with an i386 target, since someone
else already went through that exercise and posted the results here. So:

1. If performance matters, you probably need to hunt down the tool chain
required and rebuild your Ruby interpreter from source using
chip-specific optimizations.

2. Zed's numbers are exaggerated.

> 1. File open operations are slower on Windows. Period.

Frequent file opening and closing on any platform is a bad thing. If
your profiling catches your application doing that, fix it. If you've
designed it into your application, re-design. :)


> 2. The current compiler used has a significant lack of optimisation
>   compared to modern compilers (e.g., anything after 2000 -- since the
>   current compiler was released in 1998).

Well ... maybe. I think the chip-specific stuff is probably a bigger
factor than the age of the compiler, but there's no point in optimizing
with an old compiler rather than investing the energy in getting the new
one integrated.
> 
> I care, but not so much that I'm
> willing to force other precipitous decisions.

Especially since we're mostly volunteers here ... I wouldn't expect, for
example, Curt to start building chip-specific One-Click Installers or
Instant Rails.
> 
> -austin