Felix W. wrote:
about 52,000 iterations per second to 58,000… I wonder why other
should be “-O3 -march=”, where
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.
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
Felix W. 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 Mon, Sep 24, 2007 at 02:21:34PM +0900, M. Edward (Ed) Borasky wrote:
Felix W. 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. . . .
Chad P. 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 Sat, Sep 22, 2007 at 03:05:04PM +0900, Josip G. wrote:
Oh, and finally, the latest Ruby from svn…
-
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 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/
Paul B. 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”.
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 Tue, Sep 25, 2007 at 06:05:10PM +0900, Josip G. 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 Sep 20, 7:35 pm, Todd B. [email protected] 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 Sep 25, 5:25 pm, jzakiya [email protected] 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.”
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 Sep 25, 5:27 pm, jzakiya [email protected] 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 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 Oct 26, 7:59 pm, Summercool [email protected] 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.
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
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.
Charles Oliver N. 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.
All I have to say to this is: xkcd: Penises :-p
(Ok, yes, I only linked to it because mine is slower 
Regards
Stefan