How fast does your Ruby run?
I got 53648 iterations per second running the following program,
on an Intel 3.2 GHz HT, Win XP machine:
--------
C:\> ruby calculate.rb
55
Ruby 1.8.6 patch 0 on i386-mswin32
It took 18.64 seconds to run. 53648 iterations per second.
--------
n = 1_000_000
start_time = Time.now
for i in 1..n
t = (1..10).inject {|x, y| x + y }
end
finish_time = Time.now
p t
puts
print "Ruby ", RUBY_VERSION, " patch ", RUBY_PATCHLEVEL, " on ",
RUBY_PLATFORM
puts
print "It took #{finish_time - start_time} seconds to run."
print " #{(n / (finish_time - start_time)).to_i} iterations per
second.\n"
on 21.09.2007 00:49
on 21.09.2007 01:15
SpringFlowers AutumnMoon wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: > > -------- > > C:\> ruby calculate.rb > 55 > > Ruby 1.8.6 patch 0 on i386-mswin32 > It took 18.64 seconds to run. 53648 iterations per second. > I just ate your lunch. MacPro 3ghz dual duo 2gb ram. Ruby 1.8.2 on universal-darwin8.0 It took 6.383342 seconds to run. 156657 iterations per second. (I had to take out RUBY_PATCHLEVEL, as that's not defined, but I suspect I could have put a begin/rescue/end in around and STILL have eaten your lunch. LOLOLOLOL Todd
on 21.09.2007 01:22
Todd Burch wrote: > SpringFlowers AutumnMoon wrote: >> How fast does your Ruby run? >> >> I got 53648 iterations per second running the following program, >> on an Intel 3.2 GHz HT, Win XP machine: >> >> -------- >> >> C:\> ruby calculate.rb >> 55 >> >> Ruby 1.8.6 patch 0 on i386-mswin32 >> It took 18.64 seconds to run. 53648 iterations per second. >> > > I just ate your lunch. MacPro 3ghz dual duo 2gb ram. > > Ruby 1.8.2 on universal-darwin8.0 > It took 6.383342 seconds to run. 156657 iterations per second. > > (I had to take out RUBY_PATCHLEVEL, as that's not defined, but I suspect > I could have put a begin/rescue/end in around and STILL have eaten your > lunch. LOLOLOLOL > > Todd HAHAH. I love it! awesome. time for my sad reality. I think you just ate my lunch too :( C:\>ruby calculate.rb 55 Ruby 1.8.6 patch 0 on i386-mswin32 It took 22.359 seconds to run. 44724 iterations per second. Intel 2.8 GHz 1.5Gb RAM WinXP ~Jeremy
on 21.09.2007 01:35
Todd Burch wrote: > SpringFlowers AutumnMoon wrote: >> How fast does your Ruby run? > Ruby 1.8.2 on universal-darwin8.0 > It took 6.383342 seconds to run. 156657 iterations per second. > > (I had to take out RUBY_PATCHLEVEL, as that's not defined, but I suspect > I could have put a begin/rescue/end in around and STILL have eaten your > lunch. LOLOLOLOL > Ruby 1.8.2 on universal-darwin8.0 It took 5.920011 seconds to run. 168918 iterations per second. I changed the scope of x & y and eeked out some more speed. x, y = nil for i in 1..n t = (1..10).inject {|x, y| x + y } end
on 21.09.2007 01:52
On 9/20/07, SpringFlowers AutumnMoon <summercoolness@gmail.com> wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: > As you are seeing, ruby 1.8.x is painfully slow on Windows. =(
on 21.09.2007 01:55
On Sep 20, 2007, at 16:15, Todd Burch wrote: >> > suspect > I could have put a begin/rescue/end in around and STILL have eaten > your > lunch. LOLOLOLOL pwn! $ pbpaste | ruby19 55 Ruby 1.9.0 patch 0 on i686-darwin8.10.1 It took 2.838405 seconds to run. 352310 iterations per second. 2.16GHz Core 2 Duo
on 21.09.2007 02:14
On Fri, Sep 21, 2007 at 08:15:22AM +0900, Todd Burch wrote: > > > I could have put a begin/rescue/end in around and STILL have eaten your > lunch. LOLOLOLOL FreeBSD 6.2-RELEASE on a Pentium M/Centrino 1.7GHz Thinkpad R52: > ruby calculate.rb 55 Ruby 1.8.6 patch 0 on i386-freebsd6 It took 16.125757 seconds to run. 62012 iterations per second.
on 21.09.2007 02:16
SpringFlowers AutumnMoon wrote: > Ruby 1.8.6 patch 0 on i386-mswin32 > end > print "It took #{finish_time - start_time} seconds to run." > print " #{(n / (finish_time - start_time)).to_i} iterations per > second.\n" amd athlon 2500+XP processor (1883 MHz) 1GB ram -------------cygwin ruby 1.8.6---------- ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-cygwin] yes, that's on cygwin. $ ruby howquick.rb 55 Ruby 1.8.6 patch 0 on i386-cygwin It took 15.816 seconds to run. 63227 iterations per second. -------------native ruby same box 1.8.5---------- C:\ruby\bin>ruby c:\cygwin\home\rthompso\howquick.rb 55 c:/cygwin/home/rthompso/howquick.rb:14: uninitialized constant RUBY_PATCHLEVEL ( NameError) removed pathlevel .. C:\ruby\bin>ruby c:\cygwin\home\rthompso\howquick.rb 55 Ruby 1.8.5 on i386-mswin32 It took 30.782 seconds to run. 32486 iterations per second. -------------native ruby same box updated to 1.8.6---------- C:\ruby\bin>ruby c:\cygwin\home\rthompso\howquick.rb 55 Ruby 1.8.6 patch 0 on i386-mswin32 It took 24.453 seconds to run. 40894 iterations per second. ------------ruby 1.8.5 linux core2 duo gentoo 2gb RAM------- rthompso@raker ~ $ ruby howquick.rb 55 Ruby 1.8.5 patch 2 on i686-linux It took 11.779449 seconds to run. 84893 iterations per second. ------------updated ruby 1.8.6 same linux core2 duo 2gb RAM--- rthompso@raker ~ $ ruby howquick.rb 55 Ruby 1.8.6 patch 36 on i686-linux It took 9.702104 seconds to run. 103070 iterations per second.
on 21.09.2007 02:18
On Fri, Sep 21, 2007 at 08:35:16AM +0900, Todd Burch wrote: > > > > Ruby 1.8.2 on universal-darwin8.0 > It took 5.920011 seconds to run. 168918 iterations per second. > > I changed the scope of x & y and eeked out some more speed. > > x, y = nil > for i in 1..n > t = (1..10).inject {|x, y| x + y } > end That cut almost three full seconds off my time -- down to 13.829852 seconds to run, at 72307 iterations per second. Obviously, you're still kicking the crap out of my poor little Pentium M.
on 21.09.2007 02:20
Reid Thompson wrote: >> >> t = (1..10).inject {|x, y| x + y } >> puts > 55 > c:/cygwin/home/rthompso/howquick.rb:14: uninitialized constant > -------------native ruby same box updated to 1.8.6---------- > > It took 9.702104 seconds to run. 103070 iterations per > second. forgot the processor speed for the linux core2 duo model name : Intel(R) Core(TM)2 CPU 6320 @ 1.86GHz
on 21.09.2007 02:39
Eric Hodel wrote: > > pwn! > > $ pbpaste | ruby19 > 55 > > Ruby 1.9.0 patch 0 on i686-darwin8.10.1 > It took 2.838405 seconds to run. 352310 iterations per > second. > > 2.16GHz Core 2 Duo OOOOUCH!!! Ruby 1.9.0 is HOT!
on 21.09.2007 04:35
On Sep 20, 6:49 pm, SpringFlowers AutumnMoon <summercooln...@gmail.com> wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: Dual Core AMD Opteron 270 2GHz Ruby 1.8.5 on i486-linux It took 19.373381 seconds to run. 51617 iterations per second. Not too fast, but I do have a couple of Western Digital (WD1500ADFD) drives, so the I/O screams :)
on 21.09.2007 07:47
Todd Burch wrote: >> >> Ruby 1.8.6 patch 0 on i386-mswin32 >> It took 18.64 seconds to run. 53648 iterations per second. >> > > I just ate your lunch. MacPro 3ghz dual duo 2gb ram. > > Ruby 1.8.2 on universal-darwin8.0 > It took 6.383342 seconds to run. 156657 iterations per second. MacBook Pro 2.1G. I tried both Ruby and JRuby. JRuby: Ruby 1.8.5 patch 3876 on java It took 8.022 seconds to run. 124657 iterations per second. Ruby: Ruby 1.8.6 patch 0 on i686-darwin8.9.1 It took 10.262067 seconds to run. 97446 iterations per second. - Charlie
on 21.09.2007 07:51
Charles Oliver Nutter wrote:
> It took 10.262067 seconds to run. 97446 iterations per second.
I also tried Ruby 1.9 and Rubinius, but Rubinius crashed.
Ruby 1.9.0 patch 0 on i686-darwin8.10.1
It took 3.299607 seconds to run. 303066 iterations per second.
- Charlie
on 21.09.2007 08:12
On 9/21/07, Charles Oliver Nutter <charles.nutter@sun.com> wrote: > > > Wow my work machine is really bad A 2.6Ghz on XP with 512M 55 Ruby 1.8.6 patch 0 on i386-mswin32 It took 35.844 seconds to run. 27898 iterations per second.
on 21.09.2007 11:16
On Sep 21, 10:49 am, SpringFlowers AutumnMoon <summercooln...@gmail.com> wrote: > Ruby 1.8.6 patch 0 on i386-mswin32 > end > print "It took #{finish_time - start_time} seconds to run." > print " #{(n / (finish_time - start_time)).to_i} iterations per > second.\n" > -- > Posted viahttp://www.ruby-forum.com/. AMD 2.8 GHz Ubuntu 7.04 2 GB RAM geoff@geoff-laptop:~/prog/ruby$ ruby calculate.rb 55 Ruby 1.8.6 patch 0 on i686-linux It took 13.012441 seconds to run. 76849 iterations per second. And then with the addition of x, y = nil geoff@geoff-laptop:~/prog/ruby$ ruby calculate.rb 55 Ruby 1.8.6 patch 0 on i686-linux It took 12.135616 seconds to run. 82402 iterations per second.
on 21.09.2007 11:22
SpringFlowers AutumnMoon wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: Here's something interesting. The processor is Intel T7200 @ 2.00GHz, Linux Ubuntu. 1. With ruby 1.8.5. which comes packaged with Ubuntu: Ruby 1.8.5 on i486-linux It took 20.346013 seconds to run. 49149 iterations per second. 2. With ruby 1.9.0 (2006-06-08) which comes packaged in Ubuntu: Ruby 1.9.0 on i486-linux It took 23.875774 seconds to run. 41883 iterations per second. 3. With ruby 1.8.6 compiled from sources on the machine: Ruby 1.8.6 on i686-linux It took 7.107875 seconds to run. 140689 iterations per second. Obviously, the target instruction set matters quite a lot. I think I'll be compiling my own ruby from now on. :-)
on 21.09.2007 11:23
Seems like a pretty silly test, but okay... $ unset RUBYOPT && ruby1.8 /home/gga/bin/ruby/speed_test.rb && ./ruby / home/gga/bin/ruby/speed_test.rb && echo && uname -a Ruby 1.8.5 on x86_64-linux It took 14.754958 seconds to run. 67773 iterations per second. Ruby 1.9.0 on x86_64-linux It took 2.558372 seconds to run. 390873 iterations per second. Linux aura1 2.6.17-10-generic #2 SMP Tue Dec 5 21:16:35 UTC 2006 x86_64 GNU/Linux AMD 4400 2CPUs.
on 21.09.2007 12:16
Le 21 septembre à 00:49, SpringFlowers AutumnMoon a écrit :
> How fast does your Ruby run?
Ok. Since I can't possibly win this DSW, I'll try this on my slowest
machines... :)
- AMD Athlon 1.4GHz (quite busy server) :
Ruby 1.8.6 patch 0 on i386-freebsd6
It took 42.070099 seconds to run. 23769 iterations per second.
Aaand...
- PIII 500MHz (diskless workstation with very limited RAM - especially
raised from the dead just for you, people !) :
Ruby 1.8.4 patch ? on i386-freebsd6
It took 202.375195 seconds to run. 4941 iterations per second.
(Wooot !)
BTW, on the other direction :
- AMD Opteron 244 1.8GHz :
Ruby 1.8.6 patch 0 on amd64-freebsd6
It took 12.838229 seconds to run. 77892 iterations per second.
Fred
on 21.09.2007 12:58
Hi all, Ok, here's some more numbers (comparing ubuntu pre-compiled, compiled from sources and development version): * Ruby 1.8.5 shipped with Ubuntu: 30.871182 seconds * Ruby 1.8.5 compiled from sources: 12.173341 seconds (wooh, what a difference!) * Ruby 1.8.6 compiled from sources: 11.238127 * Ruby 1.9.0 (downloaded today from ruby-lang.org and compiled from sources): 3.561564 All the tests have been run on an Intel(R) Pentium(R) D CPU 2.80GHz running Kubuntu Linux 7.04 (Feisty Fawn). See ya!
on 21.09.2007 14:26
2007/9/21, SpringFlowers AutumnMoon <summercoolness@gmail.com>:
> How fast does your Ruby run?
Hi, here are my results:
**** Ubuntu GNU/Linux on a Thinkpad R52 (Intel Celeron 1.4 Ghz)
$ ruby calculate.rb
55
Ruby 1.8.5 on i486-linux
It took 20.216099 seconds to run. 49465 iterations per
second.
**** MacBook (intel dual core)
$ ruby calculate.rb
55
Ruby 1.8.2 on universal-darwin8.0
It took 11.872489 seconds to run. 84228 iterations per
second.
on 21.09.2007 15:33
2007/9/21, Jaime Iniesta <jaimeiniesta@gmail.com>: > 2007/9/21, SpringFlowers AutumnMoon <summercoolness@gmail.com>: > > How fast does your Ruby run? After submitting the results for my local machines, I thought it would be a good idea to test some servers I work with. Here it goes: *** Dreamhost shared hosting $ ruby calculate.rb 55 Ruby 1.8.5 on i386-linux It took 36.407013 seconds to run. 27467 iterations per second. *** Textdrive shared hosting $ ruby calculate.rb 55 Ruby 1.8.4 on i386-freebsd5 It took 22.436537 seconds to run. 44570 iterations per second.
on 21.09.2007 15:46
Intel Dual Core 2GHz, 2GB RAM: As posted: > ruby calculate.rb 55 Ruby 1.8.6 patch 0 on i386-mswin32 It took 15.235 seconds to run. 65638 iterations per second. with x,y = nil >ruby calculate.rb 55 Ruby 1.8.6 patch 0 on i386-mswin32 It took 13.656 seconds to run. 73227 iterations per second. Don't have 1.9 installed, I should definitely give that a try. Jason
on 21.09.2007 16:14
Josip Gracin wrote: > > > 3. With ruby 1.8.6 compiled from sources on the machine: > > Ruby 1.8.6 on i686-linux > It took 7.107875 seconds to run. 140689 iterations per > second. > > > Obviously, the target instruction set matters quite a lot. I think I'll > be compiling my own ruby from now on. :-) Make sure you use the appropriate "march=" flag when you do. See http://www.jhaampe.org/software/ruby-gcc for the details.
on 21.09.2007 16:26
Le 21 septembre à 12:14, F. Senault a écrit : > - PIII 500MHz (diskless workstation with very limited RAM - especially > raised from the dead just for you, people !) : > > Ruby 1.8.4 patch ? on i386-freebsd6 > It took 202.375195 seconds to run. 4941 iterations per second. Forgot one : - Intel Celeron 633MHz (short on RAM too) : Ruby 1.8.6 patch 0 on i386-freebsd5 It took 105.835886 seconds to run. 9448 iterations per second. (And that one is an important production machine, nothing less !) Fred
on 21.09.2007 20:20
On Sep 20, 4:49 pm, SpringFlowers AutumnMoon <summercooln...@gmail.com> wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: 3GHz Intel P4, HT Ruby 1.8.5 on i386-mswin32 It took 30.141 seconds to run. 33177 iterations per second. Ruby 1.8.6 on i386-mswin32 It took 22.422 seconds to run. 44599 iterations per second.
on 21.09.2007 21:05
On Sep 21, 6:57 am, "Imobach González Sosa" <imobac...@gmail.com> wrote: > Hi all, > > Ok, here's some more numbers (comparing ubuntu pre-compiled, compiled > from sources and development version): > > * Ruby 1.8.5 shipped with Ubuntu: 30.871182 seconds > * Ruby 1.8.5 compiled from sources: 12.173341 seconds (wooh, what a difference!) That's amazing. Are you sure the only difference was pre-built Ruby vs. built-from-source? That just seems like too big of a difference.
on 21.09.2007 21:07
On Sep 20, 4:49 pm, SpringFlowers AutumnMoon
<summercooln...@gmail.com> wrote:
> How fast does your Ruby run?
MacBook Pro 2.16 GHz
Ruby 1.8.6 patch 0 on i686-darwin8.9.1
It took 9.167413 seconds to run. 109082 iterations per
second.
Ruby 1.9.0 patch 0 on i686-darwin8.10.1
It took 3.059674 seconds to run. 326832 iterations per
second.
Seeing other 1.9 speeds got me to install it.
Chris
on 21.09.2007 22:01
Quoth F. Senault: > - Intel Celeron 633MHz (short on RAM too) : > You dreamed of a big star, he played a mean guitar. > (Pink Floyd, Welcome to the Machine) Pentium 133MHz w/ 128MiB of ram (my router) running ruby from FC6 updates: Ruby 1.8.5 patch 52 on i386-linux It took 2644.671185 seconds to run. 378 iterations per second.
on 21.09.2007 22:14
On Sat, 22 Sep 2007, Brian Adkins wrote: > That's amazing. Are you sure the only difference was pre-built Ruby > vs. built-from-source? That just seems like too big of a difference. I was also amyazed. The original poster could actually find out quite easily whether the improvement comes from recompiling: # apt-get build-dep ruby1.8 # apt-get source ruby1.8 # cd ruby1.8* # dpkg-buildpackage -rfakeroot This will build a package that's *not* optimized for the local architecture. In order to do the latter he will need to change the config/compile options in debian/rules. *t --
on 21.09.2007 22:43
On 9/21/07, SpringFlowers AutumnMoon <summercoolness@gmail.com> wrote: > How fast does your Ruby run? Hand built 1.8.6 on 2ghz MacBook, 1gig ram: RubyMate r6354 running Ruby r1.8.6 (/usr/local/bin/ruby) >>> test.rb 55 Ruby 1.8.6 patch 0 on i686-darwin8.10.1 It took 9.495808 seconds to run. 105309 iterations persecond.
on 21.09.2007 23:24
hello ! My hardware: Laptop Asus A6TC - Debian Sid i386 AMD Thurion64x2 uname -a: Linux adom 2.6.22.5 #1 SMP Wed Aug 29 01:16:06 CEST 2007 i686 GNU/Linux --------------- tests: 1) ruby compiled by : # apt-get build-dep ruby1.9 # apt-get source ruby1.9 Ruby 1.9.0 patch 0 on i686-linux It took 9.170000 seconds to run. 269313 iterations per second. 2) ruby from source (cvs) !!! Ruby 1.9.0 patch 0 on i686-linux It took 3.713144 seconds to run. 269313 iterations per second. 3) ruby from repository (without optimalization) Ruby 1.9.0 patch 0 on i686-linux It took 9.500020 seconds to run. 269313 iterations per second. 4) ruby from repository Ruby 1.8.6 patch 0 on i686-linux It took 25.030340 seconds to run. 269313 iterations per second. Summary: Do I need to try gentoo ? ;)
on 21.09.2007 23:27
On 9/21/07, SpringFlowers AutumnMoon <summercoolness@gmail.com> wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, P-III 700MHz, 384 megs of ram 55 It took 0.122343 seconds to run. 8173741 iterations per second. It's a C version though *ducks*
on 21.09.2007 23:32
xx xx wrote: > hello ! > > My hardware: > Laptop Asus A6TC - Debian Sid i386 > AMD Thurion64x2 > > uname -a: > Linux adom 2.6.22.5 #1 SMP Wed Aug 29 01:16:06 CEST 2007 i686 GNU/Linux > > --------------- > tests: > Sorry for "269313 iterations" in my previous post - i couldn't edit it btw. what is a "version though *ducks* " ?
on 22.09.2007 01:03
On 9/21/07, xx xx <pietia.moo@gmail.com> wrote: > > --------------- > > tests: > > > > > Sorry for "269313 iterations" in my previous post - i couldn't edit it > > btw. what is a "version though *ducks* " ? lol. I imagine he doesn't want to get swatted by ruby purists. He compiled into machine code instead of using the interpreter? For what it's worth, I was able to have an 800MHz machine do 30 seconds with the 1.8.6 standard build from source by disabling the GC in irb and loading via... irb> load "test.rb" Standard time during normal computer operation for executing the OP's code was around 49+/-5 seconds. Normal operation included having a heavy use network session mixed with X Windows open and a window manager. I pushed it to do less than 20 seconds by rewriting the code (cheating) to omit the inject method, making it look ugly with while loops, and also leaving out the puts/p/print methods. I will confirm that it was extremely easy to beat the one-click install on a newer/faster Windows machine with 1.8.6. Nothing against that, though, because making a clean install of anything on Windows is nothing less than an act of God (nothing against the Windows fans either; it justs seems harder than it needs to be; I think this will change eventually). I have yet to attempt Cygwin or MingW building on a Windows system, though. I haven't tried the 1.9 installer yet, either. Todd
on 22.09.2007 03:48
On Sep 21, 2007, at 02:20, Josip Gracin wrote: > Ruby 1.8.5 on i486-linux > 3. With ruby 1.8.6 compiled from sources on the machine: > > Ruby 1.8.6 on i686-linux > It took 7.107875 seconds to run. 140689 iterations per > second. > > > Obviously, the target instruction set matters quite a lot. I think > I'll be compiling my own ruby from now on. :-) How can you draw that conclusion? You used three different versions of ruby.
on 22.09.2007 06:01
Todd Benson wrote: >>> > > > a Windows system, though. I haven't tried the 1.9 installer yet, > either. > > Todd I've built using cygwin several times w/out issue. Not recently though, the setup version has been kept pretty up to date and has been speedy enough for what I use it for. ( results are posted earlier in the thread )
on 22.09.2007 07:47
Eric Hodel wrote: > > How can you draw that conclusion? You used three different versions of > ruby. You are right, that was one hasty conclusion. Here are the real results, indicating how ruby was compiled: 1. CFLAGS="-O3 -mcpu=i686 -march=i686 -mtune=i686" ./configure --target=i686-linux Ruby 1.8.5 on i686-linux It took 6.561333 seconds to run. 152408 iterations per second. 2. CFLAGS="-O3 -mcpu=i486 -march=i486 -mtune=i486" ./configure --target=i486-linux Ruby 1.8.5 on i486-linux It took 6.847393 seconds to run. 146040 iterations per second. 3. CFLAGS="-O3 -mcpu=i686 -march=i686 -mtune=i686" ./configure --target=i686-linux --enable-pthread Ruby 1.8.5 on i686-linux It took 17.856484 seconds to run. 56002 iterations per second. Note the "--enable-pthread" in the last measurement. The binary distributed with Ubuntu is compiled with pthreads.
on 22.09.2007 08:05
Josip Gracin wrote: >>> I'll be compiling my own ruby from now on. :-) > > second. > Note the "--enable-pthread" in the last measurement. The binary > distributed with Ubuntu is compiled with pthreads. > Oh, and finally, the latest Ruby from svn... 4. CFLAGS="-O3 -mcpu=i686 -march=i686 -mtune=i686" ./configure --enable-pthread Ruby 1.9.0 on i686-linux It took 2.507824 seconds to run. 398752 iterations per second.
on 22.09.2007 14:52
On 9/21/07, Imobach González Sosa <imobachgs@gmail.com> wrote: > Hi all, > > Ok, here's some more numbers (comparing ubuntu pre-compiled, compiled > from sources and development version): > > * Ruby 1.8.5 shipped with Ubuntu: 30.871182 seconds > * Ruby 1.8.5 compiled from sources: 12.173341 seconds (wooh, what a difference!) > * Ruby 1.8.6 compiled from sources: 11.238127 > * Ruby 1.9.0 (downloaded today from ruby-lang.org and compiled from > sources): 3.561564 One more strike against using Debian packaged Ruby! Just for fun, this is for a Macbook 2.16 GHz Intel Core 2 Duo with 1GB or ram (Ruby was installed using macports) 55 Ruby 1.8.6 patch 0 on i686-darwin8.10.2 It took 8.688359 seconds to run. 115096 iterations per second. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/
on 22.09.2007 17:32
Intel Dual core 3.2 GHz, Win XP machine Ruby 1.8.6 patch 0 It took 14.344 seconds to run. 69715 iterations per second. I am SO embarrassed.
on 22.09.2007 22:23
On Sat, 22 Sep 2007, Rick DeNatale wrote: >> sources): 3.561564 > > One more strike against using Debian packaged Ruby! If I infer correctly it's rather one more strike against compiling with the "--enable-pthread" switch. So while it's yet another oportunity of Debian bashing I guess the more clever option would be to ask why "--enable-pthread" sucks so bad and whether ____Ubuntu____ (note that possibly Debian uses it too, I don't know) should switch it off... *t --
on 22.09.2007 22:36
Tomas Pospisek's Mailing Lists wrote: > If I infer correctly it's rather one more strike against compiling with > the "--enable-pthread" switch. So while it's yet another oportunity of > Debian bashing I guess the more clever option would be to ask why > "--enable-pthread" sucks so bad and whether ____Ubuntu____ (note that > possibly Debian uses it too, I don't know) should switch it off... The --enable-pthread might be for compatibility with the tcl/tk package (IIRC correctly, they should either both use it or both not use it).
on 23.09.2007 00:02
On 9/22/07, Tomas Pospisek's Mailing Lists <tpo2@sourcepole.ch> wrote: > On Sat, 22 Sep 2007, Rick DeNatale wrote: > > One more strike against using Debian packaged Ruby! > > If I infer correctly it's rather one more strike against compiling with > the "--enable-pthread" switch. So while it's yet another oportunity of > Debian bashing I guess the more clever option would be to ask why > "--enable-pthread" sucks so bad and whether ____Ubuntu____ (note that > possibly Debian uses it too, I don't know) should switch it off... I'm not bashing Debian in general, just the Debian approach to Ruby packaging. In general I'm quite happy with Debian/Ubuntu, but not with deb packaged Ruby. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/
on 23.09.2007 11:09
On Sun, 23 Sep 2007, Rick DeNatale wrote: > > I'm not bashing Debian in general, just the Debian approach to Ruby packaging. > > In general I'm quite happy with Debian/Ubuntu, but not with deb packaged Ruby. Shall I bite? So what's wrong with Debian's Ruby packaging and what would be the proper way? (AFAIcan see the above problem doesn't have anything to do with Debian's packaging but instead with a compile flag?) *t --
on 23.09.2007 16:56
Tomas Pospisek's Mailing Lists wrote: > On Sun, 23 Sep 2007, Rick DeNatale wrote: > So what's wrong with Debian's Ruby packaging and what would be the > proper > way? (AFAIcan see the above problem doesn't have anything to do with > Debian's packaging but instead with a compile flag?) > *t Probably it depends on architecture of the binary-package which was prepared for. it's too "universal". for example binary packages are made por i386 , not for i686.
on 23.09.2007 17:12
SpringFlowers AutumnMoon wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: > > -------- > > C:\> ruby calculate.rb > 55 > > Ruby 1.8.6 patch 0 on i386-mswin32 > It took 18.64 seconds to run. 53648 iterations per second. > > -------- > > n = 1_000_000 > > start_time = Time.now > > for i in 1..n > t = (1..10).inject {|x, y| x + y } > end > > finish_time = Time.now > > p t > > puts > print "Ruby ", RUBY_VERSION, " patch ", RUBY_PATCHLEVEL, " on ", > RUBY_PLATFORM > > puts > print "It took #{finish_time - start_time} seconds to run." > print " #{(n / (finish_time - start_time)).to_i} iterations per > second.\n" 55 Ruby 1.8.6 patch 0 on i386-mswin32 It took 18.146 seconds to run. 55108 iterations per second. this is on a 3.2Ghz with HT, VISTA, guess vista is slower than XP
on 23.09.2007 18:59
SpringFlowers AutumnMoon wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: > > -------- > > C:\> ruby calculate.rb > 55 > > Ruby 1.8.6 patch 0 on i386-mswin32 > It took 18.64 seconds to run. 53648 iterations per second. > > -------- > > n = 1_000_000 > > start_time = Time.now > > for i in 1..n > t = (1..10).inject {|x, y| x + y } > end > > finish_time = Time.now > > p t > > puts > print "Ruby ", RUBY_VERSION, " patch ", RUBY_PATCHLEVEL, " on ", > RUBY_PLATFORM > > puts > print "It took #{finish_time - start_time} seconds to run." > print " #{(n / (finish_time - start_time)).to_i} iterations per > second.\n" Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz 800MHz FSB Ubuntu 7.04 Ruby1.8.5 on i486-Linux It took 17316402 seconds to run. 58261 iterations per second. Ruby1.9.0 on i686-Linux It took 2.24857 seconds to run. 4447227 iterations per second.
on 23.09.2007 20:24
Hi,
> How fast does your Ruby run?
Ruby 1.8.5 patch 12 on powerpc-darwin8.8.0
It took 38.723017 seconds to run. 25824 iterations per
second.
PowerPC G4, 1.42 GHz ;)
Julian
on 23.09.2007 21:13
On Mon, Sep 24, 2007 at 01:59:29AM +0900, Michael Greenly wrote: > > Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz 800MHz FSB > Ubuntu 7.04 > > Ruby1.8.5 on i486-Linux > It took 17316402 seconds to run. 58261 iterations per second. Is that missing a decimal point after the 17?
on 23.09.2007 21:32
SpringFlowers AutumnMoon wrote: > How fast does your Ruby run? > > I got 53648 iterations per second running the following program, > on an Intel 3.2 GHz HT, Win XP machine: > > -------- > > C:\> ruby calculate.rb > 55 > > Ruby 1.8.6 patch 0 on i386-mswin32 > It took 18.64 seconds to run. 53648 iterations per second. > > Gotta love the Mac: 55 Ruby 1.8.6 patch 0 on i686-darwin8.9.1 It took 7.376952 seconds to run. 135557 iterations per second. Not as fast and Todd's but still a screamer... ;)
on 23.09.2007 21:38
The performance gain I got from Ruby 1.8.6 to Ruby 1.9 is only from about 52,000 iterations per second to 58,000... I wonder why other people get so big performance gain instead. is it because they compile their only Ruby 1.9. I downloaded the Ruby 1.9 from Ruby 1.9.0 Binary (md5: 9809f6e9bc7795f83612b369e36c8724) Developer version (experimental) in http://www.ruby-lang.org/en/downloads/ for the Win XP version.
on 23.09.2007 23:12
> Hand built 1.8.6 on 2ghz MacBook, 1gig ram: > > RubyMate r6354 running Ruby r1.8.6 (/usr/local/bin/ruby) > >>> test.rb > > 55 > > Ruby 1.8.6 patch 0 on i686-darwin8.10.1 > It took 9.495808 seconds to run. 105309 iterations persecond. Followup, with the newly released 1.8.6p100 robert-mcgoverns-computer:~/Documents/Programming robertmcgovern$ ruby test.rb 55 Ruby 1.8.6 patch 110 on i686-darwin8.10.1 It took 9.955669 seconds to run. 100445 iterations persecond. Slightly slower, running on battery but I don't think it makes any difference. Rob
on 23.09.2007 23:16
In article <d7cae0a34b0eb47703e31c2ae1c8c826@ruby-forum.com>, SpringFlowers AutumnMoon <summercoolness@gmail.com> wrote: > in http://www.ruby-lang.org/en/downloads/ > > for the Win XP version. I'm not a big fan of compiling and installing bleeding-edge code... I'll wait for final releases on my system.. ;)
on 23.09.2007 23:37
On Sun, 23 Sep 2007, xx xx wrote: > it's too "universal". for example binary packages are made por i386 , > not for i686. However the data I have available indicate that compiling ruby for i486 (afaik Debian compiles for i486 and not i386) instead of against i686 doesn't matter much: On Sat, 22 Sep 2007, Josip Gracin wrote: > 2. CFLAGS="-O3 -mcpu=i486 -march=i486 -mtune=i486" ./configure > --target=i486-linux > > Ruby 1.8.5 on i486-linux > It took 6.847393 seconds to run. 146040 iterations per > second. Which would make a difference of rougly 4%. Am I misstaken? Anything else that sucks so bad with Debian packaging? *t --
on 23.09.2007 23:41
On Mon, 24 Sep 2007, Michael Greenly wrote: >> >> t = (1..10).inject {|x, y| x + y } >> puts > Ruby1.9.0 on i686-Linux > It took 2.24857 seconds to run. 4447227 iterations per second. Are you certain?!?!? That would be a 100 fold improvement?!!?!?! ?!?! *t --
on 24.09.2007 00:16
On Mon, 24 Sep 2007 06:40, Tomas Pospisek's Mailing Lists wrote: >> It took 2.24857 seconds to run. 4447227 iterations per second. > > Are you certain?!?!? That would be a 100 fold improvement?!!?!?! > ?!?! > *t I guess he typed the results instead of copying and pasting, judging by the missing period after 17 in the first result; so that may be a typo too. Anyway, here it goes: Intel(R) Pentium(R) M processor 2.00GHz Arch Linux Ruby 1.8.6 patch 36 on i686-linux It took 16.125842 seconds to run. 62012 iterations per second. Ruby 1.9.0 patch 0 on i686-linux It took 2.505766 seconds to run. 399079 iterations per second.
on 24.09.2007 00:28
SpringFlowers AutumnMoon wrote: > The performance gain I got from Ruby 1.8.6 to Ruby 1.9 is only from > about 52,000 iterations per second to 58,000... I wonder why other > people get so big performance gain instead. is it because they compile > their only Ruby 1.9. If that is true, then is the release version specifically compiled to be slow? Which compiler is the best and which settings to use for a "roll your own" ruby for windows? Unix?
on 24.09.2007 02:33
Lloyd Linklater wrote: > SpringFlowers AutumnMoon wrote: >> The performance gain I got from Ruby 1.8.6 to Ruby 1.9 is only from >> about 52,000 iterations per second to 58,000... I wonder why other >> people get so big performance gain instead. is it because they compile >> their only Ruby 1.9. > > If that is true, then is the release version specifically compiled to be > slow? Which compiler is the best and which settings to use for a "roll > your own" ruby for windows? Unix? > As far as I've been able to determine, with gcc, the compiler settings should be "-O3 -march=<architecture>", where <architecture> is the chip name, for example "-O3 -march=athlon64". There doesn't seem to be much gain from going from O2 to O3, but it's non-zero. The tests I've looked at indicate that it's the "-march" piece that does the real job. Incidentally, I saw a post go by somewhere that had "-march= -mcpu= -mtune=" flags all set. The only one you want is "-march" -- the others are redundant or ignored or both. See http://www.jhaampe.org/software/ruby-gcc for the details. I can't help you with the Microsoft or other Windows compilers. Cygwin or MSYS/MinGW compiling, on the other hand, should work the same way as Linux -- you've got gcc, so use "-march=" and "-O3".
on 24.09.2007 02:58
> >> about 52,000 iterations per second to 58,000... I wonder why other > > are redundant or ignored or both. > > See http://www.jhaampe.org/software/ruby-gcc for the details. > > I can't help you with the Microsoft or other Windows compilers. Cygwin > or MSYS/MinGW compiling, on the other hand, should work the > same way as > Linux -- you've got gcc, so use "-march=" and "-O3". > Just for the hell of it, on a Core 2 Duo @ 2GhZ: Vanilla Ubuntu Ruby from repositories $ ruby test.rb Ruby 1.8.5 on i486-linux It took 20.8315 seconds to run. 48004 iterations per second. Standard compiled from source (no compiler flags) $ ./ruby1.8.6/bin/ruby test.rb Ruby 1.8.6 on i686-linux It took 7.015534 seconds to run. 142540 iterations per second. Optimized compiled from source (CFLAGS="-O3 -march=nocona") $ ./ruby1.8.6opt/bin/ruby test.rb Ruby 1.8.6 on i686-linux It took 6.543835 seconds to run. 152815 iterations per second. Vanilla Ubuntu Ruby 1.9 from repositories $ ruby1.9 test.rb Ruby 1.9.0 on i486-linux It took 24.726563 seconds to run. 40442 iterations per second. Standard 1.9 compiled from source (no compiler flags) $ ./ruby1.9/bin/ruby test.rb Ruby 1.9.0 on i686-linux It took 2.627064 seconds to run. 380653 iterations per second. Optimized 1.9 compiled from source (CFLAGS="-O3 -march=nocona") felix@felix-laptop:~$ ./ruby1.9opt/bin/ruby test.rb Ruby 1.9.0 on i686-linux It took 2.593149 seconds to run. 385631 iterations per second. Felix
on 24.09.2007 03:50
Felix Windt wrote: >>>> about 52,000 iterations per second to 58,000... I wonder why other >> should be "-O3 -march=<architecture>", where <architecture> >> See http://www.jhaampe.org/software/ruby-gcc for the details. > > > It took 24.726563 seconds to run. 40442 iterations per second. > Ruby 1.9.0 on i686-linux > It took 2.593149 seconds to run. 385631 iterations per second. > > > Felix Yep ... those numbers are typical of what I'm seeing with the Athlon64 X2 -- I haven't run this particular test yet, but I will run it later tonight (compiled only -- I run Gentoo so I don't have a pre-compiled i486 executable to deal with). :) By the way, what compiler version are you on? I'm on 4.2.0 at the moment -- nothing newer has escaped Gentoo's QA process yet.
on 24.09.2007 04:07
> >> To: ruby-talk ML > >>>> their only Ruby 1.9. > >> name, for example "-O3 -march=athlon64". There doesn't > >> > > > > > > It took 24.726563 seconds to run. 40442 iterations per second. > > Ruby 1.9.0 on i686-linux > By the way, what compiler version are you on? I'm on 4.2.0 at > the moment > -- nothing newer has escaped Gentoo's QA process yet. Vanilla Ubuntu, which is still tracking the 4.1 branch: ~$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) I'm curious whether 4.2 would give further performance enhancements - maybe if I have some time this week I'll build a tool chain to test with. Felix
on 24.09.2007 07:22
Felix Windt wrote: > --enable-libstdcxx-debug --enable-mpfr --enable-checking=release > i486-linux-gnu > Thread model: posix > gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) > > I'm curious whether 4.2 would give further performance enhancements - maybe > if I have some time this week I'll build a tool chain to test with. > > Felix It's unlikely to be faster in a statistically significant sense. As a matter of fact, in many cases the *older* gcc versions give faster code! Poke around on Anton Ertl's Forth/VMgen site and you'll find that *his* performance hit a peak with gcc 2.95 and has been dropping steadily with each new gcc since then. :)
on 24.09.2007 15:57
On Mon, Sep 24, 2007 at 02:21:34PM +0900, M. Edward (Ed) Borasky wrote: > Felix Windt wrote: > > > > I'm curious whether 4.2 would give further performance enhancements - maybe > > if I have some time this week I'll build a tool chain to test with. > > It's unlikely to be faster in a statistically significant sense. As a > matter of fact, in many cases the *older* gcc versions give faster code! > Poke around on Anton Ertl's Forth/VMgen site and you'll find that *his* > performance hit a peak with gcc 2.95 and has been dropping steadily with > each new gcc since then. :) I find that rather surprising. The common wisdom seems to be that newer compiler versions tend to optimize more aggressively for the common case, and take longer to compile as a result -- but tend to cause problems for performance with multithreaded applications because until very recently that hasn't been a priority for most compilers. Falling performance for the same code on newer compiler versions makes me wonder what else is going on in compiler development. If you have any insights, I'd like to know about it. I wonder if Ruby 1.9 would compile with the TenDRA compiler. . . .
on 24.09.2007 16:27
Chad Perrin wrote: > I find that rather surprising. The common wisdom seems to be that newer > compiler versions tend to optimize more aggressively for the common case, > and take longer to compile as a result -- but tend to cause problems for > performance with multithreaded applications because until very recently > that hasn't been a priority for most compilers. Falling performance for > the same code on newer compiler versions makes me wonder what else is > going on in compiler development. If you have any insights, I'd like to > know about it. The phenomenon is specific to gForth/vmgen and not a general rule as far as I know. The "general rule" is that newer compilers do better on newer architectures and "about the same" in the sense of statistical significance on the older ones. gForth/vmgen has some very specific dependencies on gcc itself -- it uses some non-standard extensions to the C language in gcc and aggressively goes for putting things in registers, something most programmers wouldn't risk doing. Another example is the ATLAS linear algebra library. Again, this is highly tuned C code (and now even has some assembler kernels). GCC 3 was significantly better than early versions of GCC 4 on 32-bit architectures. I don't recall if GCC 4 is now equivalent, and the point may be moot if the assembler kernels were introduced as a result. > I wonder if Ruby 1.9 would compile with the TenDRA compiler. . . . I've never heard of it. If I had an Intel Core2 chip, I'd evaluate the Intel compiler on it, but I don't ... I'm an Intel-free zone. :)
on 24.09.2007 16:49
> Intel compiler on it, but I don't ... I'm an Intel-free zone. :) > Though I'm getting way into OT territory here - apparently gcc 4.3 will include specific architecture and tuning parameters for Core 2 processors. http://gcc.gnu.org/gcc-4.3/changes.html Felix
on 24.09.2007 17:46
On Sat, Sep 22, 2007 at 03:05:04PM +0900, Josip Gracin wrote: > Oh, and finally, the latest Ruby from svn... > > 4. CFLAGS="-O3 -mcpu=i686 -march=i686 -mtune=i686" ./configure > --enable-pthread > > Ruby 1.9.0 on i686-linux > It took 2.507824 seconds to run. 398752 iterations per > second. What does it look like without --enable-pthread? Paul
on 24.09.2007 23:45
On Mon, Sep 24, 2007 at 11:26:15PM +0900, M. Edward (Ed) Borasky wrote: > > Another example is the ATLAS linear algebra library. Again, this is > highly tuned C code (and now even has some assembler kernels). GCC 3 was > significantly better than early versions of GCC 4 on 32-bit > architectures. I don't recall if GCC 4 is now equivalent, and the point > may be moot if the assembler kernels were introduced as a result. Thanks for the info. I may have to investigate further, with this as some hints for where to start. > > > I wonder if Ruby 1.9 would compile with the TenDRA compiler. . . . > > I've never heard of it. http://www.tendra.org/about/
on 25.09.2007 11:06
Paul Brannan wrote:
> What does it look like without --enable-pthread?
Without --enable-pthread, it still gets linked with libpthread.so. And
performs as mentioned.
If I put --disable-pthread, the compile fails, saying "No rule to make
target thread_.h, needed by error.o".
on 25.09.2007 14:28
On Tue, Sep 25, 2007 at 06:05:10PM +0900, Josip Gracin wrote: > >What does it look like without --enable-pthread? > > Without --enable-pthread, it still gets linked with libpthread.so. And > performs as mentioned. > > If I put --disable-pthread, the compile fails, saying "No rule to make > target thread_.h, needed by error.o". Oh, silly me :) -- YARV uses pthread for its threading now, so of course it won't work without it. I wonder if it will build with GNU pth? Paul
on 25.09.2007 23:32
On Sep 20, 7:35 pm, Todd Burch <pro...@burchwoodusa.com> wrote: > Ruby 1.8.2 on universal-darwin8.0 > Posted viahttp://www.ruby-forum.com/. -------------------------------------------------- n = 1_000_000 start_time = Time.now for i in 1..n t = (1..10).inject {|x, y| x + y } end run_time = start_time - Time.now p t puts print "Ruby ", RUBY_VERSION, " patch ", RUBY_PATCHLEVEL, " on ", RUBY_PLATFORM puts print "It took #{runt_time} seconds to run." print " #{(n / run-time).to_i} iterations per second.\n"
on 25.09.2007 23:35
On Sep 25, 5:25 pm, jzakiya <jzak...@mail.com> wrote: > > > (I had to take out RUBY_PATCHLEVEL, as that's not defined, but I suspect > > t = (1..10).inject {|x, y| x + y } > for i in 1..n > > puts > print "It took #{runt_time} seconds to run." > print " #{(n / run-time).to_i} iterations per > second.\n" > -- opps print "It took #{run_time} seconds to run."
on 25.09.2007 23:45
On Sep 25, 5:27 pm, jzakiya <jzak...@mail.com> wrote: > > > > It took 6.383342 seconds to run. 156657 iterations per second. > > > x, y = nil > > start_time = Time.now > > print "Ruby ", RUBY_VERSION, " patch ", RUBY_PATCHLEVEL, " on ", > > RUBY_PLATFORM > > > puts > > print "It took #{runt_time} seconds to run." > > print " #{(n / run-time).to_i} iterations per > > second.\n" > > -- > > opps > print "It took #{run_time} seconds to run." opps again run_time = Time.now - start_time
on 27.10.2007 05:00
today, on the Mac OS X 10.5 Leopard Ruby 1.8.6 patch 36 on universal-darwin9.0 It took 12.960213 seconds to run. 77159 iterations per second. on the Mac mini 2.0 GHz Core 2 Duo
on 27.10.2007 07:19
On Sep 20, 2007, at 4:49 PM, SpringFlowers AutumnMoon wrote: > Ruby 1.8.6 patch 0 on i386-mswin32 > end > print "It took #{finish_time - start_time} seconds to run." > print " #{(n / (finish_time - start_time)).to_i} iterations per > second.\n" cfp:~ > cat a.rb require 'narray' n = 1_000_000 t = nil start_time = Time.now n.times{ t = NArray.int(10).indgen!(1).sum } finish_time = Time.now p t puts print "Ruby ", RUBY_VERSION, " patch ", RUBY_PATCHLEVEL, " on ", RUBY_PLATFORM puts print "It took #{finish_time - start_time} seconds to run." print " #{(n / (finish_time - start_time)).to_i} iterations per second.\n" cfp:~ > ruby a.rb 55 2GHz osx Ruby 1.8.6 patch 0 on i686-darwin8.9.1 It took 2.893815 seconds to run. 345564 iterations per second. a @ http://codeforpeople.com/
on 27.10.2007 14:00
On Oct 26, 7:59 pm, Summercool <Summercooln...@gmail.com> wrote: > today, on the Mac OS X 10.5 Leopard > > Ruby 1.8.6 patch 36 on universal-darwin9.0 > It took 12.960213 seconds to run. 77159 iterations per second. > > on the Mac mini > 2.0 GHz Core 2 Duo sorry it should have been 82,000 iterations per second. there was an iChat hogging the CPU for some reason... on the 2.4GHz Macbook Pro, I got 999,860 iterations per second.
on 27.10.2007 15:41
windows xp. intel core2 1.86GHz JRUBY: C:\jruby\jruby-trunk\bin>jruby calculate.rb 55 It took 41.125 seconds to run. 24316 iterations per second. Not so good. Let's disable ObjectSpace: C:\jruby\jruby-trunk\bin>jruby -O calculate.rb 55 It took 11.109 seconds to run. 90017 iterations per second. That was good. Now let's give it some more juice: C:\jruby\jruby-trunk\bin>jruby -J-server -O calculate.rb 55 It took 5.75 seconds to run. 173913 iterations per second. -------------------------------------------- MRI:One-Click ruby calculate.rb 55 Ruby 1.8.6 patch 0 on i386-mswin32 It took 15.828 seconds to run. 63179 iterations per second.
on 27.10.2007 20:20
Gentoo Linux on Intel Pentium 4 2.40GHz (512 KB cache): Ruby Patch Platform Seconds Iterations per second ===== ===== =================== ========= ===================== 1.8.6 111 i686-linux (gentoo) 32.801483 30486 1.8.6 5000 i686-linux 13.607635 73488 1.9.0 0 i686-linux 3.988949 250692 1.8.5 3876 java 63.589 15725 1.8.5 3876 java (-J-server) 44.173 22638 1.8.5 3876 java (-O) 36.917 27087 1.8.5 3876 java (-O -J-server) 15.194 65815 The first is the system installed ruby. The others are current svn checkouts. Regards, Daniel
on 27.10.2007 20:35
Daniel Schömer wrote: > 1.8.5 3876 java (-O -J-server) 15.194 65815 > > The first is the system installed ruby. IIRC on my Gentoo I got +80% on this particular benchmark with USE="-threads". Given this huge difference I looked at the speedup for the test suite of one of my Rails applications and got only ~ +10%. That said I use Xpath in one Ruby script and the speedup was unbelievable : maybe +1000% (yes 3 zeros, the script took more than a minute, maybe several and with USE="-threads" it went through the data in less than ten seconds). I believe Ruby compiled with pthread is known to have performance problems (at least on Linux as I've seen reports of such behavior on Linux before)... If you want speed on Linux (and maybe other flavours of Unix), you should look at compiling it without pthread. Warning: as some classes may use system libs that *are* compiled with pthread, you might not have this choice (IIRC the pthread support is there just to support such libraries). If someone knows more about this subject (and how to tell if compiling without pthread is safe), I'd love to know the details. Regards, Lionel
on 27.10.2007 21:01
Charles Oliver Nutter wrote:
> It took 10.262067 seconds to run. 97446 iterations per second.
Updated for current JRuby trunk:
JRuby:
Ruby 1.8.5 patch 3876 on java
It took 7.237 seconds to run. 138178 iterations per second.
If I make it run a bit longer, the disparity is greater:
n = 10_000_000
JRuby:
Ruby 1.8.5 patch 3876 on java
It took 61.918 seconds to run. 161503 iterations per second.
Ruby:
Ruby 1.8.6 patch 0 on i686-darwin8.9.1
It took 107.181442 seconds to run. 93299 iterations per second.
- Charlie
on 27.10.2007 21:04
All I have to say to this is: http://xkcd.com/194/ :-p (Ok, yes, I only linked to it because mine is slower ;-) Regards Stefan
on 27.10.2007 21:20
Daniel Schömer wrote:
> 1.8.5 3876 java (-O -J-server) 15.194 65815
FYI, we're debating making ObjectSpace something you must turn *on* at
command line or through a library call, rather than something you have
to turn off. Practically nothing uses it, and it's a huge perf hit for
JRuby.
Thoughts?
- Charlie
on 27.10.2007 21:23
Charles Oliver Nutter wrote: >> 1.8.5 3876 java (-O) 36.917 27087 > > Just a question -- assuming it's off by default, how do you know when you need to turn it on?
on 27.10.2007 21:32
Lionel Bouton wrote: >> 1.8.5 3876 java (-O) 36.917 27087 > minute, maybe several and with USE="-threads" it went through the data > > If someone knows more about this subject (and how to tell if compiling > without pthread is safe), I'd love to know the details. > > Regards, > > Lionel > > Well, on Gentoo you'd need to turn off the "threads" USE flag globally. Either everything (in this case Ruby and Tcl/Tk for sure) is with "threads" or everything is without it. Personally, on my two UP systems (non-SMP) I turn it off and on my dual-core SMP system I turn it on. But that's really superstition more than anything based on measurements. I can't speak for other distros, Windows, Intel vs. AMD, etc. But as far as I know on Gentoo it's safe to go "-threads" across the board even on an SMP system. I'm going to go ahead and turn it off on the dual-core and see what happens -- I'm wrapping up some benchmarking tests this weekend so it's a good time to play around with it in a controlled environment.
on 27.10.2007 21:34
Daniel Schömer wrote: > 1.8.5 3876 java (-O -J-server) 15.194 65815 > > The first is the system installed ruby. The others are current > svn checkouts. > > Regards, > Daniel What is "patch 5000"??
on 28.10.2007 01:43
M. Edward (Ed) Borasky wrote: > Charles Oliver Nutter wrote: >> FYI, we're debating making ObjectSpace something you must turn *on* at >> command line or through a library call, rather than something you have >> to turn off. Practically nothing uses it, and it's a huge perf hit for >> JRuby. >> > Just a question -- assuming it's off by default, how do you know when > you need to turn it on? We'd print a warning if it's used without being enabled. - Charlie
on 28.10.2007 02:01
Charles Oliver Nutter wrote: > We'd print a warning if it's used without being enabled. > > - Charlie > > Let me re-phrase that ... how do I know when I'm coding that I'm not going to ask for it? Do I need to explicitly call/require/include something to get it?
on 28.10.2007 02:04
Charles Oliver Nutter: > > Just a question -- assuming it's off by default, how do you know when > > you need to turn it on? > > We'd print a warning if it's used without being enabled. > > - Charlie Wouldn't it be better to throw?
on 28.10.2007 03:10
On Gentoo, Ruby with threads is ridiculously slow. Machine is an Xeon E5320 1.86GHz. $ ruby-nothreads calculate.rb 55 Ruby 1.8.6 patch 111 on i686-linux It took 9.759139 seconds to run. 102468 iterations per second. $ ruby-threads calculate.rb 55 Ruby 1.8.6 patch 111 on i686-linux It took 21.473884 seconds to run. 46568 iterations per second.
on 28.10.2007 06:01
John Lam (DLR) wrote: > Charles Oliver Nutter: > >>> Just a question -- assuming it's off by default, how do you know when >>> you need to turn it on? >> We'd print a warning if it's used without being enabled. >> >> - Charlie > > > Wouldn't it be better to throw? Maybe? - Charlie
on 28.10.2007 06:05
M. Edward (Ed) Borasky wrote: > Let me re-phrase that ... how do I know when I'm coding that I'm not > going to ask for it? Do I need to explicitly call/require/include > something to get it? Well, you need to explicitly reference ObjectSpace in most cases to access it, right? In general, the tricky bit is that there's at least one key library in stdlib that depends on ObjectSpace: test/unit, which uses it to locate tests. However I've implemented in JRuby the ability to walk all child classes from a parent class, which provides the each_object(Class) used in test/unit. Currently, you can turn off ObjectSpace support in JRuby and still have test/unit run. Raising an error might be a better way to ensure people don't run code without ObjectSpace enabled, certainly. But maybe they don't care? It's an open question at the moment, but I don't see that there's any way ObjectSpace is going to have good performance on these new implementations where we don't have intimate control over memory and GC. I expect this is going to be a concern for IronRuby/Ruby.NET too. As far as I know, JRuby's the only general-purpose VM implementation of Ruby that's even *attempted* to make ObjectSpace work. - Charlie
on 28.10.2007 06:27
On Oct 27, 2007, at 11:04 PM, Charles Oliver Nutter wrote: > Raising an error might be a better way to ensure people don't run > code without ObjectSpace enabled, certainly. But maybe they don't > care? they care.... why not just use autoload charles? a @ http://codeforpeople.com/
on 28.10.2007 06:47
ara.t.howard wrote: > > On Oct 27, 2007, at 11:04 PM, Charles Oliver Nutter wrote: > >> Raising an error might be a better way to ensure people don't run code >> without ObjectSpace enabled, certainly. But maybe they don't care? > > they care.... why not just use autoload charles? Because ObjectSpace needs to be loaded/enabled *before* the objects you want to track come into existance. Unlike Ruby's simple GC and memory model, in JRuby we have to explicitly add objects created to a walkable list. There's no capability on most modern GCed VMs to walk the heap at will. Because of that, any objects created before ObjectSpace is enabled would not be visible during any subsequent walk. Generally, autoload would be far too late. - Charlie
on 28.10.2007 07:06
On Oct 27, 2007, at 11:46 PM, Charles Oliver Nutter wrote: > Because ObjectSpace needs to be loaded/enabled *before* the objects > you want to track come into existance. Unlike Ruby's simple GC and > memory model, in JRuby we have to explicitly add objects created to > a walkable list. There's no capability on most modern GCed VMs to > walk the heap at will. Because of that, any objects created before > ObjectSpace is enabled would not be visible during any subsequent > walk. Generally, autoload would be far too late. hmmm. an exception seems best then - force the require up front. or, is there perhaps a lighter weight method to mark things so you *could* bootstrap ObjectSpace once it was loaded? cheers. a @ http://codeforpeople.com/
on 28.10.2007 07:18
ara.t.howard wrote: > > hmmm. an exception seems best then - force the require up front. or, > is there perhaps a lighter weight method to mark things so you *could* > bootstrap ObjectSpace once it was loaded? Not really; we've made it as lightweight as possible. The problem is that there's no capability in the JVM to say "let me walk all objects", largely because of how that would impact GC operation and security (should objects created in other classloaders be walkable? internal JVM objects? should you be able to reach objects you'd *never* be able to construct or reference yourself? so many questions). So the only way to ever be able to reach objects in the future is to have a reference to them somewhere. So we create a very lightweight linked list of references to all objects created. However it gets more complicated: ObjectSpace references shouldn't keep objects from getting collected. So every reference is a Java weak reference, and we periodically clean the list of dead references. Tracking every object created + weak references + periodic cleanup = slow. So ObjectSpace either needs to be there when the object is created, or you must accept that you can't ever walk it. - Charlie
on 28.10.2007 07:23
Charles Oliver Nutter wrote: > In general, the tricky bit is that there's at least one key library in > stdlib that depends on ObjectSpace: test/unit, which uses it to locate > tests. However I've implemented in JRuby the ability to walk all child > classes from a parent class, which provides the each_object(Class) used > in test/unit. The dependence on ObjectSpace is kind of nasty, isn't it? A library shouldn't use ObjectSpace in this way, because what it finds there may depend on whether GC has run recently or not. Good to hear you found a way to support it anyway, though. Does your mechanism to walk child classes prevent them from being collected, if there are no other references to them? If so, then it isn't quite bug-compatible (though it is unlikely to matter): require 'test/unit' def add_a_test_case str puts "adding test case #{str}" Class.new(Test::Unit::TestCase).class_eval do define_method :test_foo do puts "running test case #{str}" end end end at_exit { GC.start } at_exit { add_a_test_case 1 } at_exit { add_a_test_case 2 } at_exit { add_a_test_case 3 } at_exit { add_a_test_case 4 } __END__ adding test case 4 adding test case 3 adding test case 2 adding test case 1 Loaded suite - Started running test case 1 . Finished in 0.000918 seconds. 1 tests, 0 assertions, 0 failures, 0 errors
on 28.10.2007 07:28
Joel VanderWerf wrote: > Does your mechanism to walk child classes prevent them from being > collected, if there are no other references to them? If so, then it > isn't quite bug-compatible (though it is unlikely to matter): Oh, just saw your other post: you use weak refs, so the behavior should be like ObjectSpace.
on 28.10.2007 07:35
Joel VanderWerf wrote: > The dependence on ObjectSpace is kind of nasty, isn't it? A library > shouldn't use ObjectSpace in this way, because what it finds there may > depend on whether GC has run recently or not. Yes, ObjectSpace is a useful tool for walking the heap when you really want to, but it's not deterministic about whether or when it will find the object(s) you want. So I agree it's a bad feature to use as part of libraries you want to work the same way every time. In the case of test/unit, most TestCase descendants get hard-referenced as classes assigned to constants somewhere. However if you constructed a test case as follows: Class.new(Test::Unit::TestCase) { def test_something; end } ...it may or may not run with the default loader. > Good to hear you found a way to support it anyway, though. > > Does your mechanism to walk child classes prevent them from being > collected, if there are no other references to them? If so, then it > isn't quite bug-compatible (though it is unlikely to matter): No, the references to child classes are all weak references; if they go away, the references will go away. It's a much smaller price to pay than attaching weak references to *all* constructed objects (to my knowledge, it costs almost nothing, and test/unit still works. The typical way I think people would fix test/unit's use of ObjectSpace would be to add a Class#inherited hook that records all subclasses of TestCase. But nobody's gone ahead with that change yet. - Charlie
on 28.10.2007 07:45
On Oct 28, 2007, at 12:17 AM, Charles Oliver Nutter wrote: > Not really; we've made it as lightweight as possible. The problem > is that there's no capability in the JVM to say "let me walk all > objects", largely because of how that would impact GC operation and > security (should objects created in other classloaders be walkable? > internal JVM objects? should you be able to reach objects you'd > *never* be able to construct or reference yourself? so many > questions). better you than me ;-) > > So ObjectSpace either needs to be there when the object is created, > or you must accept that you can't ever walk it. > hmmm. ok i'm brainstorming here which you can ignore if you like as i know less that nothing about jvms or implementing ruby but here goes: what if you could invert the problem? what i objects knew about the global ObjectSpaceThang and could be forced to register themselves on demand somehow? without a reference i've no idea how, just throwing that out there. or, another stupid idea, what if the objects themselves were the tree/graph of weak references parent -> children. crawling it would be, um, fun - but you could prune dead objects *only* when walking the graph. this should be possible in ruby since you always have the notion of a parent object - which is Object - so all objects should be either reachable or leaks. now back to drinking my regularly scheduled beer... cheers. a @ http://codeforpeople.com/
on 28.10.2007 10:05
M. Edward (Ed) Borasky wrote: > > Daniel Schömer wrote: >> [...] >> 1.8.6 5000 i686-linux 13.607635 73488 >> [...] > What is "patch 5000"?? That's what ruby from the svn checkout http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8 thinks is it's patchlevel. | # cat ruby_1_8/version.h | #define RUBY_VERSION "1.8.6" | #define RUBY_RELEASE_DATE "2007-10-26" | #define RUBY_VERSION_CODE 186 | #define RUBY_RELEASE_CODE 20071026 | #define RUBY_PATCHLEVEL 5000 | | #define RUBY_VERSION_MAJOR 1 | #define RUBY_VERSION_MINOR 8 | #define RUBY_VERSION_TEENY 6 | #define RUBY_RELEASE_YEAR 2007 | #define RUBY_RELEASE_MONTH 10 | #define RUBY_RELEASE_DAY 26 | | #ifdef RUBY_EXTERN | RUBY_EXTERN const char ruby_version[]; | RUBY_EXTERN const char ruby_release_date[]; | RUBY_EXTERN const char ruby_platform[]; | RUBY_EXTERN const int ruby_patchlevel; | #endif Daniel
on 28.10.2007 11:05
Lionel Bouton wrote: >> 1.8.5 3876 java (-O) 36.917 27087 >> 1.8.5 3876 java (-O -J-server) 15.194 65815 >> >> The first is the system installed ruby. > IIRC on my Gentoo I got +80% on this particular benchmark with > USE="-threads". Given this huge difference I looked at the speedup for > the test suite of one of my Rails applications and got only ~ +10%. > [...] Now I recompiled ruby without threads: Ruby Patch Platform Seconds Iterations/s ===== ===== ============================ ========= ============ 1.8.6 111 i686-linux (gentoo) 32.801483 30486 1.8.6 111 i686-linux (gentoo -threads) 15.776961 63383 Wow, that's better. Since I only have a few packages compiled with threads, I try to recompile them without. Daniel
on 28.10.2007 18:55
On Oct 28, 2007, at 12:04 AM, Charles Oliver Nutter wrote:
> locate tests.
Couldn't test/unit define an inherited() hook and locate test cases
that way? I haven't looked at the code, but it seems like that could
work.
James Edward Gray II
on 28.10.2007 19:08
James Edward Gray II wrote: >> In general, the tricky bit is that there's at least one key library >> in stdlib that depends on ObjectSpace: test/unit, which uses it to >> locate tests. > > Couldn't test/unit define an inherited() hook and locate test cases > that way? I haven't looked at the code, but it seems like that could > work. > > James Edward Gray II Yes, it's very easy to do so. In fact, it's so easy that I implemented it a few months back: http://ola-bini.blogspot.com/2007/07/objectspace-to-have-or-not-to-have.html I didn't integrate it with test/unit at that point, but it should be easy-easy to do. Cheers -- Ola Bini (http://ola-bini.blogspot.com) JRuby Core Developer Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) Practical JRuby on Rails (http://apress.com/book/view/9781590598818) "Yields falsehood when quined" yields falsehood when quined.
on 28.10.2007 19:32
Ola Bini wrote: > > I didn't integrate it with test/unit at that point, but it should be > easy-easy to do. I think Ryan Davis (current test/unit maintainer) would probably like to have that patch. Send it his way. - Charlie
on 28.10.2007 20:33
On Sep 20, 4:49 pm, SpringFlowers AutumnMoon
<summercooln...@gmail.com> wrote:
> How fast does your Ruby run?
How fast does my Ruby run?! You've never heard of The Millenium Ruby?
It's the version that made the GNU/Kessel run in less than 12
parsecs!
It's run faster than Imperial programming languages. Not the local
bulk Java installs, mind you. I'm talking the big MS C# installs.
She's fast enough for you, old man.
Regards,
Dan
on 29.10.2007 00:32
> Followup, with the newly released 1.8.6p100 > > robert-mcgoverns-computer:~/Documents/Programming robertmcgovern$ ruby test.rb > 55 > > Ruby 1.8.6 patch 110 on i686-darwin8.10.1 > It took 9.955669 seconds to run. 100445 iterations persecond. > > Slightly slower, running on battery but I don't think it makes any difference. A followup on myself now that Leopard is out and installed on my MacBook. On AC, with Normal performance selected the results are: Ruby 1.8.6 patch 36 on universal-darwin9.0 It took 12.038167 seconds to run. 83069 iterations persecond. On AC, with Better Performance selected: Ruby 1.8.6 patch 36 on universal-darwin9.0 It took 12.112343 seconds to run. 82560 iterations persecond. On Battery, Better Battery Life: Ruby 1.8.6 patch 36 on universal-darwin9.0 It took 12.095676 seconds to run. 82674 iterations persecond. On Battery, Better Performance: Ruby 1.8.6 patch 36 on universal-darwin9.0 It took 12.10441 seconds to run. 82614 iterations persecond. So roughly 3 seconds slower overall for Leopards own 1.8.6 vs hand built 1.8.6 on Tiger. Need to build my own 1.8.6 on Leopard to see what that brings. Also no real difference between various settings (wasn't sure if any noticeable CPU throttling would occur).
on 29.10.2007 16:02
On Oct 28, 2007, at 1:33 PM, Daniel Berger wrote: > How fast does my Ruby run?! You've never heard of The Millenium Ruby? > It's the version that made the GNU/Kessel run in less than 12 > parsecs! > > It's run faster than Imperial programming languages. Not the local > bulk Java installs, mind you. I'm talking the big MS C# installs. > > She's fast enough for you, old man. touche´ a @ http://codeforpeople.com/
on 04.11.2007 01:34
>windows xp. intel core2 1.86GHz > > JRUBY: > > C:\jruby\jruby-trunk\bin>jruby calculate.rb > 55 > > It took 41.125 seconds to run. 24316 iterations per > second. > > Not so good. Let's disable ObjectSpace: > C:\jruby\jruby-trunk\bin>jruby -O calculate.rb > 55 > > It took 11.109 seconds to run. 90017 iterations per > second. > > That was good. Now let's give it some more juice: > C:\jruby\jruby-trunk\bin>jruby -J-server -O calculate.rb > 55 > > It took 5.75 seconds to run. 173913 iterations per > second. > -------------------------------------------- > MRI:One-Click > ruby calculate.rb > 55 > > Ruby 1.8.6 patch 0 on i386-mswin32 > It took 15.828 seconds to run. 63179 iterations per > second. #testing 1.9, yep it's fast; C:\cygwin\ruby1.9\bin>ruby calculate.rb 55 Ruby 1.9.0 patch 0 on i386-cygwin It took 3.847 seconds to run. 259942 iterations per second.
on 18.03.2009 01:33
on a 1.86GHz Intel Core 2 Duo CPU (Intel 6320) running Win XP: Ruby 1.9.1 patch 0 on i386-mswin32 It took 5.9375 seconds to run. 168421 iterations per second.