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


 

Forums >

comp.lang.ruby

Re: How fast does your Ruby run?

Felix Windt

9/24/2007 2:05:00 AM

> -----Original Message-----
> From: M. Edward (Ed) Borasky [mailto:znmeb@cesmail.net]
> Sent: Sunday, September 23, 2007 6:50 PM
> To: ruby-talk ML
> Subject: Re: How fast does your Ruby run?
>
> Felix Windt wrote:
> >> -----Original Message-----
> >> From: M. Edward (Ed) Borasky [mailto:znmeb@cesmail.net]
> >> Sent: Sunday, September 23, 2007 5:32 PM
> >> To: ruby-talk ML
> >> Subject: Re: How fast does your Ruby run?
> >>
> >> 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/softwar... 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
>
> 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.

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
4 Answers

M. Edward (Ed) Borasky

9/24/2007 5:22:00 AM

0

Felix Windt wrote:
> 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

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. :)

Chad Perrin

9/24/2007 1:56:00 PM

0

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. . . .

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
Baltasar Gracian: "A wise man gets more from his enemies than a fool from
his friends."

M. Edward (Ed) Borasky

9/24/2007 2:26:00 PM

0

Chad Perrin wrote:
> 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.

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. :)

Chad Perrin

9/24/2007 9:44:00 PM

0

On Mon, Sep 24, 2007 at 11:26:15PM +0900, M. Edward (Ed) Borasky wrote:
> 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.

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....

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."