barjunk wrote:
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= - I usually set it 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