From: Wilson Bilkovich Date: 2006-11-01T01:43:01+09:00 Subject: Re: Ruby performance on Windows XP On 10/30/06, M. Edward (Ed) Borasky wrote: > Austin Ziegler wrote: > > On 10/30/06, Zed A. Shaw 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. > > My tests (looking for the benchmark code now.. without much luck thus far..) stressed file read and object allocation ops, rather than aiming for a 'pure CPU' test of Ruby. I did this because I feel it best reflects running test suites, and that's the slowest thing I do with Ruby. Heh. In that kind of environment, the gap between Linux and Win32 was much, much wider. This makes me believe it is a platform problem, not (mostly) a compiler issue. I get 0% speedup on this test by switching from VC6 to VC7.1, and I tried twenty or thirty different combinations of compiler flags.