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-pthreadThanks! 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.
-RogerPosted via http://www.ruby-forum.com/.
use narray whenever possible.
James B. wrote:
E) None of the above
Well … my answer was, “if it’s a notebook, I’ll give you $50 for it.”
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 of
main’ 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 of
static’ 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