Austin Z. wrote:
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:
-
If performance matters, you probably need to hunt down the tool chain
required and rebuild your Ruby interpreter from source using
chip-specific optimizations.
-
Zed’s numbers are exaggerated.
- 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. 
- 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.