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.
Stuart
--
More details would be useful. Raising this on the Rails list would be
even more useful.
-austin
On 10/30/06, 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.
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
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.
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.
--
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
O'Reilly Media - Technology and Business Training -- The Mongrel Book
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
Dark Ambient 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.Stuart
Hmmm ... lots of questions ... but the other posters are right ... this
is really a Rails list question.
1. How much memory does the server have?
2. Is the 50 megabytes for ruby.exe growing?
3. It has the processor pegged at 99 percent (I'm assuming a 1P). Is it
doing any reading or writing?
4. Is this Instant Rails?
Austin Ziegler 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.More details would be useful. Raising this on the Rails list would be
even more useful.-austin
Hey,
I've noticed the same problem on my Windows XP installation, so I
switched to Linux (SuSE 10.1) and haven't looked back since!
Posting to the rails list might help, someone there will most likely
have solved it by now...
rubyonrails-talk@googlegroups.com
Also, I noticed stopping/starting the server seems to help. Not a
solution, but it'll save you that 5+ minutes between page refreshes!
Cheery-o
Gustav Paul
gustav@rails.co.za
On 10/30/06, Dark Ambient <sambient@gmail.com> wrote:
Zed A. Shaw 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.com/y5kwou\.
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
On Tue, 31 Oct 2006 01:45:52 +0900 > "Dark Ambient" <sambient@gmail.com> wrote:
in a development mode.
2- Sometimes I've seen Ruby going past 129 megs of memory.
3- As far as the reading and writing , I can't tell, at least not from the
server logs.
4-Yep, it's Instant Rails.
Stuart
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Dark Ambient 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.
>
> Stuart
>Hmmm ... lots of questions ... but the other posters are right ... this
is really a Rails list question.1. How much memory does the server have?
2. Is the 50 megabytes for ruby.exe growing?
3. It has the processor pegged at 99 percent (I'm assuming a 1P). Is it
doing any reading or writing?
4. Is this Instant Rails?Ed, my apologies, as this is not a server environment. This is a laptop
--
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
On 10/30/06, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
Daniel Berger wrote:
Zed A. Shaw 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.
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.
On Tue, 31 Oct 2006 01:45:52 +0900 >> "Dark Ambient" <sambient@gmail.com> wrote:
Austin Ziegler 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.
>
> More details would be useful. Raising this on the Rails list would be
> even more useful.
>
> -austin
I did raise this on the Rails list, yet it gathered little interest nor
anyone else experiencing similar behaviour
Hey,
I've noticed the same problem on my Windows XP installation, so I
switched to Linux (SuSE 10.1) and haven't looked back since!
Posting to the rails list might help, someone there will most likely
have solved it by now...
I have plans at some point soon to switch over to Linux, possibly Ubuntu.
Not sure which version. at this point.
rubyonrails-talk@googlegroups.com
Also, I noticed stopping/starting the server seems to help. Not a
solution, but it'll save you that 5+ minutes between page refreshes!
Yep, that is exactly what I've been doing. This is not production so it's
acceptable. Annoying but acceptable.
Cheery-o
Gustav Paul
gustav@rails.co.za
Stuart
On 10/30/06, Gustav Paul <gustav@rails.co.za> wrote:
> On 10/30/06, Dark Ambient <sambient@gmail.com> wrote:
--
Austin Ziegler 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.
On 10/30/06, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
-austin
Dark Ambient wrote:
Dark Ambient 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.
>
> Stuart
>Hmmm ... lots of questions ... but the other posters are right ... this
is really a Rails list question.1. How much memory does the server have?
2. Is the 50 megabytes for ruby.exe growing?
3. It has the processor pegged at 99 percent (I'm assuming a 1P). Is it
doing any reading or writing?
4. Is this Instant Rails?Ed, my apologies, as this is not a server environment. This is a laptop
in a development mode.
2- Sometimes I've seen Ruby going past 129 megs of memory.
3- As far as the reading and writing , I can't tell, at least not from the
server logs.
4-Yep, it's Instant Rails.Stuart
1. You can add the I/O counters in the Task Manager display; you don't
need to use server logs
2. Ouch! Some *really expensive* laptops have decent hard drives in
them, but the typical laptops are optimized for low-power and low
battery consumption. Even if you're running off AC power, they sometimes
shut down the hard drive if it's idle for a couple of minutes.
Still, I'd look first for some kind of application level problem before
hunting for platform issues. I haven't done enough Rails development to
know what the diagnostic tools are, but I do know they are there, and
more are being contributed every day from the community.
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Dark Ambient wrote:
I have plans at some point soon to switch over to Linux, possibly Ubuntu.
Not sure which version. at this point.
What are your criteria for choosing a Linux distro? There's actually a
web site that will walk you through the decision. I've forgotten what it
is, though -- I made my choice a couple of years ago and *then* took the
test. It got the right answer.
Seriously, though, Ubuntu is probably the most popular "community
desktop" Linux. If you're more interested in a server, though, CentOS,
Debian stable or Fedora might be a better choice. You'll have to manage
the Ruby and Rails packages yourself -- the "stable" versions are
ancient if they even exist.
If you like learning about Linux and want the latest stable software and
want to have things performance-tuned to your hardware, I can recommend
Gentoo. The Ruby and Rails packages generally show up in Gentoo within a
day or so of release, and with a little prodding, you can file an
enhancement bug in their Bugzilla and get beta stuff in. They have a
fairly complete list of Ruby packages already.
rubyonrails-talk@googlegroups.com
Also, I noticed stopping/starting the server seems to help. Not a
solution, but it'll save you that 5+ minutes between page refreshes!Yep, that is exactly what I've been doing. This is not production so it's
acceptable. Annoying but acceptable.
Annoying isn't acceptable in my book. Your most precious resource is
your time! "It isn't production" means it isn't wasting *other peoples'*
time. Get it fixed!
P.S.: I haven't seen anything in *this* thread so far that would tell me
-- someone who does performance engineering for a living -- that your
problem is in fact Windows-related and will go away when you move to
Linux! Sorry, Zed :).
I did run my CPU-bound Ruby Matrix benchmark a couple of days ago on my
dual-booted laptop and there was a significant slowdown from the
Gentoo-optimized (gcc 4.1.1 -O2 -march=athlon-xp) Ruby interpreter on
Gentoo Linux to the One-Click Ruby with Windows XP Professional on the
same hardware.
I think that's going to get fixed when Austin and Curt get the Microsoft
folks and their tool chain playing nice with Ruby. I'll probably have to
go tweaking the Gentoo Ruby to catch up.
My One-Click / Cygwin numbers are different:
One-Click
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Ah, but I am.
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):
---------------------
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.
--
Robert W. Oliver II
President, OCS Solutions, Inc. - Web Hosting and Development
Toll-Free Phone - 1-800-672-8415
OCS Ruby Forums - http://www.rubyforums.com/
My Blog - http://www.rwoliver.com/
I want to second my vote for Gentoo.
I think its the best Linux distribution. It isn't for everyone, but it does
do most tasks well. It works well as a server, and as a desktop.
The compile times can be slow for the desktop (especially the KDE compile,
which can take a full day sometimes), but the pros of Gentoo outweigh the
cons in my opinion.
The best part about Gentoo is portage. It lets you manage every piece of
software on your system in an eloquent way. No more fumbling around with
RPM's (aka Redhat) or worrying about packages not being current (Debian
stable). Portage simply lets you keep things up to date and handles
dependencies better than Yum or Apt-get ever dreamed of doing!
If that weren't enough, Gentoo has native ports of most Ruby gems, so emerge
rmagick for example works nicely too. When you emerge rubygems, and then
run something like emerge rmagick, it will put a gem entry in the gem list
--local command, unlike Debian. In other words, Gentoo's emerge and Ruby's
gems don't fight each other like they do on most other distros.
The /etc/make.conf lets you decide what features you want on your system.
Taking the time to customize your USE flags is well worth it, as you will
always get the support you need in the software you install without even
having to worry about it. For example, using the ruby USE flag will enable
ruby support in any program that has support for it.
Also, Gentoo's install procedure teaches you quite a bit about Linux.
You'll know more about your system after doing it, and have a leg up on
knowing how to use Linux right from the start.
I'll get off my soapbox now about the joys of Gentoo
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Still, I'd look first for some kind of application level problem before
hunting for platform issues. I haven't done enough Rails development to
know what the diagnostic tools are, but I do know they are there, and
more are being contributed every day from the community.
--
Robert W. Oliver II
President, OCS Solutions, Inc. - Web Hosting and Development
Toll-Free Phone - 1-800-672-8415
OCS Ruby Forums - http://www.rubyforums.com/
My Blog - http://www.rwoliver.com/
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.
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.
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.
>
Robert Oliver wrote:
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Ah, but I am.
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).
Dark Ambient wrote:
> I have plans at some point soon to switch over to Linux, possibly
Ubuntu.
> Not sure which version. at this point.What are your criteria for choosing a Linux distro? There's actually a
web site that will walk you through the decision. I've forgotten what it
is, though -- I made my choice a couple of years ago and *then* took the
test. It got the right answer.
I'll take a look around for that site. I don't believe I have any
criteria. I do not perceive a day I'll be hosting my own apps, so the
server criteria is not important. I guess ease of use,for installing and
updating Ruby and Rails since that is the primary reason to run Linux.
Seriously, though, Ubuntu is probably the most popular "community
desktop" Linux. If you're more interested in a server, though, CentOS,
Debian stable or Fedora might be a better choice. You'll have to manage
the Ruby and Rails packages yourself -- the "stable" versions are
ancient if they even exist.If you like learning about Linux and want the latest stable software and
want to have things performance-tuned to your hardware, I can recommend
Gentoo. The Ruby and Rails packages generally show up in Gentoo within a
day or so of release, and with a little prodding, you can file an
enhancement bug in their Bugzilla and get beta stuff in. They have a
fairly complete list of Ruby packages already.
I had a look over at the Gentoo site after reading this. The screenshots
showed Gnome. Having played around with a few live cd's recently I guess I'm
leaning towards KDE. I'd assume running it under Gentoo is not a problem.
Stuart
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Robert Oliver wrote:
If that weren't enough, Gentoo has native ports of most Ruby gems, so
emerge
rmagick for example works nicely too. When you emerge rubygems, and then
run something like emerge rmagick, it will put a gem entry in the gem list
--local command, unlike Debian. In other words, Gentoo's emerge and Ruby's
gems don't fight each other like they do on most other distros.
Yeah ... and when a new release comes out, assuming they haven't already
done so, you can go into their Bugzilla and say "time to do a version
bump on ..." and they usually get to it if it's got a maintainer. And if
it doesn't have a maintainer, you probably want to be looking for
alternatives.
Also, Gentoo's install procedure teaches you quite a bit about Linux.
You'll know more about your system after doing it, and have a leg up on
knowing how to use Linux right from the start.
One caution with that is that Gentoo administration knowledge doesn't
translate immediately into Red Hat/Fedora/CentOS or Debian/Ubuntu
administration knowledge. The Gentoo people have gone out of their way
to make things easy, as have the Red Hat and Debian people, but all the
config files are in different places on the three variants. I haven't
the foggiest idea, for example, how to configure vsftpd on a Red Hat or
Debian box, but I can do it in my sleep on Gentoo.
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.