Any tricks to speed up ruby?

Wondering if anybody had suggestions for how to speed up 1.8.6 on an old
mac os x ppc. Thoughts?
Thanks.
-Roger

From: “Roger P.” [email protected]

Wondering if anybody had suggestions for how to speed up 1.8.6 on an old
mac os x ppc. Thoughts?

Not sure if this applies to OS X or not, but there have been some posts
recently
showing speed gains when one rebuilds 1.8.x configured with
–disable-pthread
(if I recall correctly.)

Regards,

Bill

Not sure if this applies to OS X or not, but there have been some posts
recently
showing speed gains when one rebuilds 1.8.x configured with
–disable-pthread

Thanks! Now if I can just figure out how to check if mine is built with
pthreads enabled…
-Roger

Roger P. wrote:

Wondering if anybody had suggestions for how to speed up 1.8.6 on an old
mac os x ppc. Thoughts?

Before this goes too far, the answer “Use C” would be considered:

A) Helpful
B) Trolling
C) Flame-bait
D) Laughable
E) None of the above


James B.

“I have the uncomfortable feeling that others are making a religion
out of it, as if the conceptual problems of programming could be
solved by a single trick, by a simple form of coding discipline!”

  • Edsger Dijkstra

On Tue, 15 Jan 2008, Roger P. wrote:

Not sure if this applies to OS X or not, but there have been some posts
recently
showing speed gains when one rebuilds 1.8.x configured with
–disable-pthread

Thanks! Now if I can just figure out how to check if mine is built with
pthreads enabled…

tpo@petertosh:~$ ldd which ruby
[…]
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7e8e000)

This one has’em.
*t

On 14.01.2008 19:55, Bill K. wrote:

From: “Roger P.” [email protected]

Wondering if anybody had suggestions for how to speed up 1.8.6 on an old
mac os x ppc. Thoughts?

Not sure if this applies to OS X or not, but there have been some posts recently
showing speed gains when one rebuilds 1.8.x configured with --disable-pthread
(if I recall correctly.)

I also believe to remember that optimization options made a significant
difference.

Roger, you are sure that you have exhausted all optimizations of Ruby
code, are you?

Kind regards

robert

Unfortunately it’s for a rails app so I am unequivocally (except for
maybe using evented mongrel) stuck with the default app performance.
Thanks for the tips on the optimizations!

Roger, you are sure that you have exhausted all optimizations of Ruby
code, are you?

Kind regards

robert

Before this goes too far, the answer “Use C” would be considered:

A) Helpful
B) Trolling
C) Flame-bait
D) Laughable
E) None of the above

I like it!
“Ruby is so slow! I can’t believe no one out there has ways to optimize
1.8.6! Terrible!”
Bait thrown.
lol
Thanks.
-Roger

On Tue, 15 Jan 2008, James B. wrote:

E) None of the above
Helpfully trolling with laughable flamebait?

http://weblog.textdrive.com/article/175/rails-optimizing-resource-usage

John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
New Zealand

If you have a Rails app that is taking a long time in Ruby code, then
you obviously have a compute-intensive action. Perhaps you could find
the most expensive part of that action and rewrite it in C using ruby-
inline (rubyinline | software projects | by ryan davis). If you
haven’t looked into this, and if you really need to write some tight C
code, then you will kiss the feet of Ryan D. for making it all so
easy.

On Jan 14, 2008, at 20:23 , s.ross wrote:

If you have a Rails app that is taking a long time in Ruby code,
then you obviously have a compute-intensive action. Perhaps you
could find the most expensive part of that action and rewrite it in
C using ruby-inline (http://www.zenspider.com/ZSS/Products/
RubyInline/). If you haven’t looked into this, and if you really
need to write some tight C code, then you will kiss the feet of Ryan
Davis for making it all so easy.

…at least take me out for a drink first…

eww

Ground on which you walk, then, Ryan.

eeewwww ;/

tomas pospisek wrote:

Thanks! Now if I can just figure out how to check if mine is built with
pthreads enabled…

tpo@petertosh:~$ ldd which ruby
[…]
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7e8e000)

This one has’em.

That is not necessarily true. It’s possible to have ruby compiled with
–disable-pthread and yet have libpthread linked in. At least it works
that way on FreeBSD. [1]

Daniel

[1]http://lists.freebsd.org/pipermail/freebsd-ports/2006-March/030691.html

On Jan 14, 2008, at 20:23 , s.ross wrote:

some tight C code, then you will kiss the feet of Ryan D. for
making it all so easy.

On Jan 14, 2008, at 8:30 PM, Ryan D. wrote:

…at least take me out for a drink first…
eww

On Jan 15, 2008 5:26 PM, s.ross [email protected] wrote:

Ground on which you walk, then, Ryan.
eeewwww ;/

What… and waste a good drink!!!

Mikel

On Jan 14, 2008, at 11:05 AM, Roger P. wrote:

Wondering if anybody had suggestions for how to speed up 1.8.6 on
an old
mac os x ppc. Thoughts?
Thanks.
-Roger

Posted via http://www.ruby-forum.com/.

use narray whenever possible.

a @ http://codeforpeople.com/

James B. wrote:

E) None of the above

Well … my answer was, “if it’s a notebook, I’ll give you $50 for it.”
:slight_smile:

Seriously, though, the answer “Buy a faster Mac” would be considered:

A) Cheating
B) Lazy
C) A wiser use of resources than trying to tweak Ruby 1.8.6
D) Premature optimization
E) All of the above

So … I assume you tried

$ export CFLAGS=‘march=ppc -O3’
$ ./configure
$ make

It’s an old trick, I believe the kde folks do it (I may be wrong)

Instead of creating lots and lots of .o’s and linking them…

Pull all the .c files into one stonking great .c file and compile
that with…

-fwhole-program' Assume that the current compilation unit represents whole program being compiled. All public functions and variables with the exception ofmain’ and those merged by attribute
externally_visible' become static functions and in a affect gets more aggressively optimized by interprocedural optimizers. While this option is equivalent to proper use ofstatic’ keyword for
programs consisting of single file, in combination with option
`–combine’ this flag can be used to compile most of smaller scale
C programs since the functions and variables become local for the
whole combined compilation unit, not for the single source file
itself.

Takes forever and needs a huge amount of RAM, but it gives the
optimizer more freedom.

I wonder how hard it would be to tweak the ruby Makefile into doing
that?

John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
New Zealand

James B. wrote:

E) None of the above
Heh, same question for “Use JRuby”…

  • Charlie

John C. wrote:

 exception of `main' and those merged by attribute

Takes forever and needs a huge amount of RAM, but it gives the

It’s an interesting thought. However, I wasn’t able to get gcc 4.2.2 to
do some simpler things, like profile-based optimization, on the Ruby
source, so I wouldn’t expect something that complex to work out of the
box. There are a lot of great things in gcc, but not many of them are as
well tested as, say, the standard modular C library or program, and, of
course, the Linux kernel.

As far as I know, “-O3 -march=” is about the best
you can get out of gcc without a lot of work. And there are a lot more
things you can do at the Ruby source level that have a bigger payoff
than that does.

On Jan 16, 2008, at 7:04 PM, John C. wrote:

factors up to 2x but usually near 1x for compiler
optimization tweaks

This is getting off the Ruby topic, but I think you’re being unfair to
optimizers (or rather, those who write them). The great thing about
optimizers is that we can write clear and expressive code and not
worry so much about strength reduction or loop unrolling or all those
other things optimizers do for us. Honestly, does it make sense to you
to read code like this:

a = (a << 1) + 1;

-or-

a *= 3;

The performance difference in a tight loop would be noticeable, but
the next person to pick up the code would probably get a quizzical
look on his or her face reading it. So the benchmark improvement may
be between 1 and 2 percent, but the maintainability improvement could
be of far greater benefit.

I’m not too familiar with gcc’s global opts, but these are the most
dangerous, but at the same time least obvious ones. If the optimizer
gets it wrong, the code can break in the oddest ways; however, when
the optimizer nails a global opt, it can make a difference you might
never have predicted.

I am truly a fan of compiler optimizations because they fall into the
“geez, that really is smart stuff” category. Still, you are absolutely
correct that a better algorithm will win almost every time.

Just my $.02 :slight_smile: