Re: Compile time options

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