[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Ruby performance on Windows XP

Zed A. Shaw

10/30/2006 5:56:00 PM

On Tue, 31 Oct 2006 01:45:52 +0900
"Dark Ambient" <sambient@gmail.com> wrote:

> While I am working in Rails, I'm noticing that Ruby many times completely
> dogs the system
> taking forever to reload a page.
> Reading under task manager I'm seeing that ruby.exe is CPU = 99 and Mem
> Usage = 50,000K
> I'm not sure what to do and have no idea how to debug it.
> There are times it take 5+ minutes to reload a page.

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.

Yet, nobody can explain it or seems to actually care since we all know that Ruby is perfection from the gods and should not be questioned.

--
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.ze...
http://safari.oreilly.com/... -- The Mongrel Book
http://mongrel.ruby...
http://www.lingr.com/room/3... -- Come get help.
7 Answers

Daniel Berger

10/30/2006 6:17:00 PM

0

Zed A. Shaw wrote:
> On Tue, 31 Oct 2006 01:45:52 +0900
> "Dark Ambient" <sambient@gmail.com> wrote:
>
> > While I am working in Rails, I'm noticing that Ruby many times completely
> > dogs the system
> > taking forever to reload a page.
> > Reading under task manager I'm seeing that ruby.exe is CPU = 99 and Mem
> > Usage = 50,000K
> > I'm not sure what to do and have no idea how to debug it.
> > There are times it take 5+ minutes to reload a page.
>
> 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.
>
> Yet, nobody can explain it or seems to actually care since we all know that Ruby is perfection from the gods and should not be questioned.

See http://tinyurl.....

Short version: Windows has a slower FS and performs IO operations more
slowly than Linux. You'll see similar slowdowns in Perl and Python.

This isn't to say that Ruby couldn't do better on Windows, but it's not
as simple as you might think. For example, I once wrote a C extension
for ReadFileEx() and compared it against Ruby's IO.read, thinking it
might bring a significant speed improvement. I was wrong.

Regards,

Dan

M. Edward (Ed) Borasky

10/30/2006 9:13:00 PM

0

Daniel Berger wrote:
> Zed A. Shaw wrote:
>> On Tue, 31 Oct 2006 01:45:52 +0900
>> "Dark Ambient" <sambient@gmail.com> wrote:
>>
>>> While I am working in Rails, I'm noticing that Ruby many times completely
>>> dogs the system
>>> taking forever to reload a page.
>>> Reading under task manager I'm seeing that ruby.exe is CPU = 99 and Mem
>>> Usage = 50,000K
>>> I'm not sure what to do and have no idea how to debug it.
>>> There are times it take 5+ minutes to reload a page.
>> 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.
>>
>> Yet, nobody can explain it or seems to actually care since we all know that Ruby is perfection from the gods and should not be questioned.
>
> See http://tinyurl.....

Hmmm ... I looked at that thread ... seems I was a participant. :)

>
> Short version: Windows has a slower FS and performs IO operations more
> slowly than Linux. You'll see similar slowdowns in Perl and Python.

I'll say now what I said then, with the caveat that the only Windows
system I have available for testing is a laptop with what must be the
slowest hard drive available -- in other words, meaningless for a
discussion of Windows server filesystem performance.

What I said then is that I don't see any reason why a Windows
performance engineer can't tune a Windows (NTFS) filesystem so its
performance is as good as ext3 on the same hardware. I'm sure the Red
Hat marketing guys will be more than happy to shove benchmarks down my
throat to counter that, but they *aren't* in the business of tuning
Windows servers!

So ... some brief hints on I/O tuning for Windows. In the following,
assume Ruby/Rails/Some Web Server/Some Database/Windows server(s):

1. Different parts of the stack have different I/O footprints. In
particular, the database is the one you want to look at first. The most
important thing to know about your application is the ratio of database
reads to database writes. The I/O subsystem handles them differently and
the tuning strategies are different.

2. Assuming a pure Windows environment (Window 2003 Server, IIS 6 and
SQL Server 2005) it's possible to have all of those components reside in
the same server and tuned for efficient operation. It's really *not*
possible with older versions of any of them. Introducing any
non-Microsoft component (PostgreSQL or MySQL, Apache, etc.) makes the
job harder but it's still possible.

3. The I/O subsystem includes the disks, controllers *and* memory.
Again, the Microsoft-only solutions are tunable easily, but with a
little more effort you can make an open-source stack work well with only
the OS being Microsoft.

In general, you want enough memory so that the minimum amount of
physical I/O is done, but not so much that the OS runs out of table
space managing it. The way you figure this out is to run performance
tests with varying amounts of memory on real workloads and looking at
the performance monitor statistics. The Windows 2003 Server Resource Kit
has all of the details and the tools.

4. At the hardware level, there is a fundamental tradeoff between disk
space and speed in a RAID controller. RAID 5 gives you the most space
and the least speed, and RAID 10 gives you the most speed and the least
space. There are other tuning tricks for SANs and other high-end I/O
subsystems. If you can afford one of them, you can also afford to have
the vendor tune them for you. :)

A couple of years ago, Windows servers certainly weren't competitive
with Linux servers. But Microsoft has worked hard to close the gap, and
they continue to do so. I suppose when the high-end Vista server TPC
benchmarks start showing up, we'll see where things stand. In the
interim, if you have to or want to run Microsoft servers, at least use
the most recent software and pick up the Resource Kit.

Austin Ziegler

10/30/2006 10:23:00 PM

0

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.

> Yet, nobody can explain it or seems to actually care since we all know
> that Ruby is perfection from the gods and should not be questioned.

Gee. There've been at least two explanations given. By me. One of which
was in a thread in the last week.

1. File open operations are slower on Windows. Period.
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).

So no, Zed, your wounded act doesn't actually buy you anything here,
because (1) I can explain it and (2) I care, but not so much that I'm
willing to force other precipitous decisions.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

M. Edward (Ed) Borasky

10/30/2006 11:28:00 PM

0

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

M. Edward (Ed) Borasky

10/30/2006 11:39:00 PM

0

Robert Oliver wrote:
> On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>>
>> 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):
>
>
> My One-Click / Cygwin numbers are different:
>
> One-Click
> ---------------------
> Total Ruby benchmark time: 13.172000 0.031000 13.203000 ( 13.922000)
>
> Cygwin
> --------------------
> Total Ruby benchmark time: 8.906000 0.016000 8.922000 ( 9.375000)
>
> In my tests, Cygwin comes out much faster.
>
Interesting ... have you posted your benchmark code? Do you have the
setup to profile the Ruby interpreter running it? (I think everything is
available in CygWin, including the Ruby source).

Wilson Bilkovich

10/31/2006 4:43:00 PM

0

On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> 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.
> >

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.

M. Edward (Ed) Borasky

11/1/2006 5:57:00 AM

0

Wilson Bilkovich wrote:
> 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.

In a related development, it took some doing, but I managed to get the
CygWin compiler to build Ruby today. On a P4 compiled with O2 and
"march=pentium4" it was still a dead heat between the recompiled Cygwin
Ruby and the One-Click Ruby on my matrix benchmark. I managed to get a
*very small* improvement by going to O3. Not enough to claim success, in
other words.

I'm probably going to load the Beta Windows Vista Ani B so graciously
handed out at RubyConf on my Athlon T-Bird, since I just stuffed a new
hard drive in it. Once that's done, I'll grab Visual Studio Express and
SQL Server 2005 express and see what sort of magic I can make happen
with NTFS.
>
>