Speed issue on Windows
Larry Kelly
platforms. I'm finding much slower on Windows, especially Windows 2003
Server.
--
Posted via http://www.ruby-forum.com/.
Daniel Berger
What exactly are you finding slow? Also, I've noticed that I/O in
general is slower on Windows compared with other platforms, for
example. In addition, what version of Ruby are you using? Did you
build it yourself? If so, with what compiler and what options?
Regards,
Dan
M. Edward (Ed) Borasky
> Larry Kelly wrote:
>
>> What progress is being made to improve Ruby's speed on Windows
>> platforms. I'm finding much slower on Windows, especially Windows 2003
>> Server.
>>
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>
> What exactly are you finding slow? Also, I've noticed that I/O in
> general is slower on Windows compared with other platforms, for
> example.
general" on Windows slower than, say, Linux or BSD? Remember, NTFS is a
journaling filesystem and is tunable, so you should compare Windows
(server??) I/O performance with, say, Linux, using properly tuned
journaling filesystems and identical (RAIDed) hardware. I think you'll
find that if you give a Windows performance engineer a chance to tune
the Windows server and a Linux performance engineer a chance to tune
the Linux server, the two platforms will be competitive.
Come back to me in a couple of weeks; I'm taking a Windows internals
course and I expect to learn the Windows piece of that performance
engineering toolset. I've already got the Linux piece pretty well under
control, and I don't know anything about BSD.
--
M. Edward (Ed) Borasky
rtilley
> What progress is being made to improve Ruby's speed on Windows
> platforms. I'm finding much slower on Windows, especially Windows 2003
> Server.
>
How are you using Ruby? I find its performance acceptable on XP and
2003. I use both Python and Ruby for many common systems administration
and automation tasks. IMO, Python and Ruby perform about the same. In
some areas, Ruby is faster... I've found this to be especially true when
working with WMI.
Wilson Bilkovich
I've found Ruby IO and database connectivity to be significantly
slower on Windows (identical and near-identical hardware) than on
Linux. Even IRB takes a noticeably longer time to reach a usable
state. A particularly nasty test is timing a script using ruby
-rprofile. The profiling overhead seems to be much greater in
Windows, which points at some kind of underlying problem.
Sadly, I don't know enough about instrumenting compiled code to point
at the problem.
M. Edward (Ed) Borasky
Hmmm ... I'm not sure how many different versions of the Ruby
interpreter there are for Windows. Are you using Curt Hibbs' One Click
Installer, which, IIRC, was compiled with the native Microsoft Visual
Studio? Some of the older versions may have been compiled with CygWin.
M. Edward (Ed) Borasky
Linux and XP Professional, and I've got CygWin on the Windows side. If
there are some reasonable benchmarks in Ruby, I could run them with the
CygWin Ruby (1.8.4 IIRC), Curt Hibbs' One Click and the stock Gentoo
Ruby (compiled with gcc 3.4 and optimized O3 with march=pentium4). To
keep things fair, I'll stick to processor-bound benchmarks; I'm not sure
it's valid to compare NTFS with ext2 filesystems.
Anybody here have any favorite Ruby benchmarks? In the absence of any
other ideas, I'll probably do a 100x100 matrix factorization using the
standard Matrix/Mathn/Rational/Complex packages. That should give the
interpreter a pretty good workout.
--
Wilson Bilkovich
I've had this experience with both the one-click, and with versions
I've built myself using Visual Studio 2K3 and 6.0.
Until I saw this thread, I assumed this was common knowledge. If
that's not the case, I can stage some kind of benchmark between Linux
and Windows on identical hardware.
--Wilson.
Wilson Bilkovich
I don't have two identical boxes right next to each other right now, but:
WinXP SP2, dual Xeon 2.8GHz, 2GB of RAM: 5.031 seconds.
Ubuntu 5.10, single P4 3.0GHz, 1GB of RAM: 2.110 seconds.
Obviously the hardware isn't the same, but they should be much, much
closer than that.
cal.rb is a good choice (in my opinion) because it creates and
compares a very large number of Rational and Fixnum objects.
On 3/26/06, M. Edward (Ed) Borasky <zn...@cesmail.net> wrote:
Joel VanderWerf
> Try running the built-in sample "cal.rb" with ruby -rprofile.
> I don't have two identical boxes right next to each other right now, but:
> WinXP SP2, dual Xeon 2.8GHz, 2GB of RAM: 5.031 seconds.
> Ubuntu 5.10, single P4 3.0GHz, 1GB of RAM: 2.110 seconds.
>
> Obviously the hardware isn't the same, but they should be much, much
> closer than that.
> cal.rb is a good choice (in my opinion) because it creates and
> compares a very large number of Rational and Fixnum objects.
4.94 sec WinXP SP2, single Pentium M, 1.7GHz, 512MB
1-click installer
2.32 sec Ubuntu 5.10, single Pentium M, 1.7GHz, 512MB
built with default build options
I took the best run out of 10 or so on each platform. Not building the
windows version with architecture specific options might account for
some of the difference.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Larry Kelly
One example.
Webrick on Fedorora C5. starts up in 3 to 5 seconds.
Webrick on Windows 2003 Server takes 30 to 40 seconds on the same
hardware.
I've tried this on 700mhz and 3ghz machines. Results are about the same.
In all cases, OS was installed with normal defaults, no attempt made to
tune anything.
-Larry
Austin Ziegler
> Daniel Berger wrote:
>> Larry Kelly wrote:
>>> What progress is being made to improve Ruby's speed on Windows
>>> platforms. I'm finding much slower on Windows, especially Windows
>>> 2003 Server.
>> general is slower on Windows compared with other platforms, for
>> example.
> OK, *my* turn to ask detailed questions. :) How specifically is "I/O
> in general" on Windows slower than, say, Linux or BSD?
File open operations are generally slower on Windows than other
platforms. Once a file is open, Windows can perform about as well as any
other operating system with a journaling filesystem. Some of the
open-time performance can be recovered by turning off "access-time"
tracking, but Windows is generally slower on those operations.
Solaris 10 claims a significant performance improvement over almost
anything else right now.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Wilson Bilkovich
I just built several versions of Ruby 1.8.4 using various
optimizations, including -G7 -Ox (target P4/Xeon architecture, maximum
optimization), and compared them to the binaries from ruby-mswin32 and
the one click installer.
They all actually performed slightly worse than the default settings.
Looks like it's not a problem with the compiler flags (which seem finely tuned).
I also tried throwing "WITHOUT_PTHREADS" into the Makefile, but since
it's not a configure.bat option on Win32, I wasn't surprised when it
didn't change anything.
--Wilson.
M. Edward (Ed) Borasky
Austin Ziegler wrote:
> Solaris 10 claims a significant performance improvement over almost
> anything else right now.
>
Solaris also has some nifty OS-level performance measuring and tuning
tools. Coincidence? I think not!
Jim V. Tess
> Try running the built-in sample "cal.rb" with ruby -rprofile.
> I don't have two identical boxes right next to each other right now,
> but:
> WinXP SP2, dual Xeon 2.8GHz, 2GB of RAM: 5.031 seconds.
> Ubuntu 5.10, single P4 3.0GHz, 1GB of RAM: 2.110 seconds.
I built Ruby with VC++ 2005 from recent source (1.8.4 doesn't compile
under VC++ 2005). My times were:
Ruby 1.8.4 preview 3: 5.59 seconds
Ruby 1.9 w/ VC++ 2005: 1.49 seconds ***
***This isn't a fair comparison, however, because I notice that the call
counts are quite different between the two runs--presumably due to
source changes since 1.8.4.
I have run other comparisons between the two, and I find the VC++ 2005
version to be anywhere from 10 to >100% faster; in particular, bignum
arithmetic is over twice as fast.
Roger Pack
just file I/O. And is there an answer? A better compiler?
Thanks!
--
Posted via http://www.ruby-forum.com/.
Luis Lavena
> What progress is being made to improve Ruby's speed on Windows
> platforms. I'm finding much slower on Windows, especially Windows 2003
> Server.
Ok, I'm jumping too late on this thread.
The current build of ruby (the official one located at ruby-lang page)
is the same bundled into One-Click-Installer (OCI).
That version was built with VC6, which compared to VC8 perform worse:
As the summary of the tests indicates, all were performed under the same
machine.
To make this simple: it's true, current distribution/build of ruby
perform worse than linux counterparts.
NOTE: this isn't a cientific test, but something average-joe could
deduce after continous use of Ruby.
This discusion was raised (by me) in the ruby-core mailing list too:
[ruby-core:12305]
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12305
and the available paths, with pro and cons:
http://www.ruby-forum.com/topic/126416#566835
I just can say 'we' are working hard to get a better build of Ruby for
Windows.
More details will come in the following weeks.
Regards,
Luis
PS: I just reply this message, since this already was a heated talk on
ruby-core and last year too. It seems it araise from time to time.
Roger Pack
> That [official] version was built with VC6, which compared to VC8 perform worse:
ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] (official build)
time elapsed: 13.516 sec.
time elapsed: 13.485 sec.
time elapsed: 13.485 sec.
time elapsed: 13.5 sec.
time elapsed: 13.485 sec.
ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32_80] VC 8.0
time elapsed: 10.516 sec.
time elapsed: 10.531 sec.
time elapsed: 10.516 sec.
time elapsed: 10.531 sec.
time elapsed: 10.515 sec.
apparently :)
>
> As the summary of the tests indicates, all were performed under the same
> machine.
It would be nice to see the comparison run on linux (same machine), too.
> To make this simple: it's true, current distribution/build of ruby
> perform worse than linux counterparts.
> I just can say 'we' are working hard to get a better build of Ruby for
> Windows.
Thanks for your work on that. I know some of us use win32 and suffer :)
-Roger
M. Edward (Ed) Borasky
Speaking of Ruby, Windows and dual-booted machines, I recently decided
to rebuild my dual-booted laptop and load a few Windows test and
development tools on the Windows partition. The Linux-side rebuild is
still in progress, but I should be able to try some simple things over
the weekend. I'm holding off on Ruby until the One-Click is released,
though, and I will *not* be loading Cygwin (or VC6, for that matter). I
think I have enough disk space for Visual Studio Express and Komodo (and
SwiftForth) :), but that's about it.
Luis Lavena
>>
>> As the summary of the tests indicates, all were performed under the same
>> machine.
> It would be nice to see the comparison run on linux (same machine), too.
>
It is!, read to the bottom after the EXPERIMENTAL STUFF WARNING! ;-)
(Starting line 82)
#--
# OS:
# Ubuntu 7.04 Feisty Fawn
# Linux 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686
GNU/Linux
#++
>> To make this simple: it's true, current distribution/build of ruby
>> perform worse than linux counterparts.
>
>> I just can say 'we' are working hard to get a better build of Ruby for
>> Windows.
>
> Thanks for your work on that. I know some of us use win32 and suffer :)
I know and share your pain, but still I got so many rewards developing
under windows that cannot take the whole platform down just due Ruby :-)
Regards,
Luis
Roger Pack
>> perform worse than linux counterparts.
I have finally gotten what I perceive as a 'working' version of mingw
ruby for windows. It seems to indeed be faster than the MSVC version
(!)
MSVC version:
G:\upillar>c:\ruby\bin\ruby -e "a = Time.new; 20000.times do 'a'*20000
end; print Time.new - a"
9.922
mingw (new) version:
G:\upillar>ruby -e "a = Time.new; 20000.times do 'a'*20000 end; print
Time.new - a"
6.656
So 30% faster.
If anybody would like to help me alpha test this, I have a distro
available for download at http://doachristianturndaily.info/ruby_distro/
with install instructions located there.
Let me know of any problems.