barjunk wrote:
I'm goofing around with compiling ruby from source.
Are there "favorite" or recommended compile time options that folks
use?
I'm sure it matters what arch is being used...I'm using Intel and PPC
machines.
I've been compiling it with:
configure --prefix=/usr
but wondered if there might be other options I should be
considering...maybe compiler optimization?
Hi Mike,
It's definitely a good thing to specify the architecture of the chip you're using. You may be giving up on portability, but that probably doesn't concern you unless you're planning on redistributing? I use sun cc, and the option is -xtarget=<pltfrm> - I usually set it <pltfrm> to "opteron" or "v8plusa"(-march or -mtune on gcc?). I don't use gcc much, but I'm hoping it should be easy for you to find the gcc equivalents here for the options mentioned.
It's definitely a good thing to go away from having a bald $CFLAGS, but compiler optimization is a tightrope sport, and more is not necessarily better in terms of performance. And you can sometimes lose correct behavior too. I tend to use -xO4 (on gcc this is -O4). cranking up levels beyond didn't help performance for me.
I also tell the compiler to attempt to inline where ever possible(-xinline=%auto on sun cc), it helps a bit, but not too much, since Ruby has many recursive calls, and they're non trivial enough to confuse a compilers inlining capabilities.
sun cc also has flags to inline code across files at link time, called "-xipo"(which you'll need to find the gcc equivalent for). This can cause your executable to become bigger of course. I also use "-g" - since it provides helpful info while not taking away from performance when I use -xO2 or higher.
The README doesn't specify any options.
'configure --help' showed that I might want to use enable-thread..but
NO! Please do not use --enable-pthreads. Thats an effective way to kill your performance. That triggers a lot of getcontext/setcontext code to get processed into the VM, and these are heavy calls, that can drop your performance by as much as 50%. Here's a writeup on the topic I posted on ruby-core a couple of months ago:
I've seen huge performance enhancements by not using "--enable-pthreads" too. I initially began to use it after the Ruby build admonished me for trying link to the Tk library(which on Solaris is built with threading support) without using --enable-pthreads for Ruby. But it turned out to be a bad idea for performance since it makes the interpretor invoke a *lot* of getcontext calls that pull down the performance by about 50% in cases.
I'm not sure why the --enable-pthreads uses the *context calls based implementation. The ruby build messages talk about frequent crashes if a pthreads based tcl/tk is linked into a non-pthreaded Ruby. I though that perhaps, having extensions that invoked threads would change the context from beneath the Ruby interpretor and leave it in an inconsistent state if Ruby didn't store it away first. So I built an extension that created threads and did some trivial computations(I did check to make sure that these weren't optimized away by the compiler). But that didn't cause ruby 1.8.6 to crash(I haven't tried on 1.9).
What advantages are obtained by using --enable-pthreads in Ruby 1.8? I'm also curious if someone has gotten Ruby(built without --enable-pthreads) to work successfully(without crashes) with tck/tk libraries with threading support built in.
I'm not using that sort of thing at the moment, and I wasn't sure if
it is by default turned on anyway.
No, it's not.
-ps
ยทยทยท
Mike B.
--
Prashant Srinivasan
F/OSS Enthusiast
Sun Microsystems, Inc.
http://blogs.sun.com/prashant
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A