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/.
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
···
From: "Roger Pack" <rogerpack2005@gmail.com>
Roger Pack 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 Britt
"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
use narray whenever possible.
···
On Jan 14, 2008, at 11:05 AM, Roger Pack 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/\.
--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama
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
···
--
Posted via http://www.ruby-forum.com/\.
F
···
On Jan 14, 2008 4:17 PM, James Britt <james.britt@gmail.com> wrote:
Roger Pack 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 Britt"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
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
···
On 14.01.2008 19:55, Bill Kelly wrote:
From: "Roger Pack" <rogerpack2005@gmail.com>
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.)
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
···
--
Posted via http://www.ruby-forum.com/\.
Helpfully trolling with laughable flamebait?
http://weblog.textdrive.com/article/175/rails-optimizing-resource-usage
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand
···
On Tue, 15 Jan 2008, James Britt wrote:
Roger Pack 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 Britt wrote:
Roger Pack 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
Heh, same question for "Use JRuby"...
- Charlie
James Britt wrote:
Roger Pack 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
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
James Britt wrote:
Roger Pack 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
Use Pascal.
A recent thread showed how slow Ruby is at generating
a string in which each character in the original string is
duplicated.
// Pascal (FreePascal)
uses sysutils { for timing }, strutils { for DupeString };
function dup_chars( var s: ansistring ): ansistring;
var
out: ansistring;
i: longint;
c: char;
begin
setlength( out, length(s) * 2 );
for i := 1 to length(s) do
begin
c := s[i];
out[2*i-1] := c;
out[2*i] := c;
end;
exit( out )
end;
var
s : ansistring;
when : tDateTime;
begin
s := dupeString( 'abc', 1000000 );
when := Time;
dup_chars( s );
writeln( ((time - when) * secsPerDay):0:3, ' seconds' )
end.
tpo@petertosh:~$ ldd `which ruby`
[...]
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7e8e000)
This one has'em.
*t
···
On Tue, 15 Jan 2008, Roger Pack 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...
--
-----------------------------------------------------------------------
Tomas Pospisek
http://sourcepole.com - Linux & Open Source Solutions
------------------------------------------------------------------------
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
--
Posted via http://www.ruby-forum.com/\.
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 Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand
So ... I assume you tried
$ export CFLAGS='march=ppc -O3' # march actually doesn't work on mac's
$ ./configure
$ make
Wow that does indeed help (once figured out). for me on my G4 it was
(after I figured out I had a 7450 processor)
export CFLAGS='-mtune=7450 -mcpu=7450 -fast -fPIC'
and compile with --disable-pthread
and voila, a faster Ruby (not sure if the real reason was the compiler
flags, the pthread, or the updated version from p110 to p114, but
something helped it--I'm guessing it was the compiler options).
new ruby with compiler options:
time ./ruby -e "10000000.times {}"
real 0m4.049s
old ruby (the mac osx port one):
time ruby -e "10000000.times {}"
real 0m5.400s
Wow it's a wonder they don't automatically set these up at compile time
to be optimized since they're so helpful.
Unfortunately gcc on mac's doesn't seem to have the -fwhole_program (at
least mine doesn't), so will have to wait to try that one till I'm back
in x86 land. Thanks for your help!
-R
···
--
Posted via http://www.ruby-forum.com/\.
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.
···
On Jan 14, 2008, at 2:05 PM, Roger Pack wrote:
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
--
Posted via http://www.ruby-forum.com/\.
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
John Carter wrote:
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 Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand
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=<your processor type>" 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.
I suspect --disable-pthread had the largest impact. The cost of memory
allocations can be high when linking with the threading library. Re-run
your tests without the other options if you want to verify.
I'm also surprised you got improved performance with -fPIC. I thought
position-independant code was supposed to run slower, usually.
Paul
···
On Wed, Mar 12, 2008 at 04:58:27PM +0900, Roger Pack wrote:
Wow that does indeed help (once figured out). for me on my G4 it was
(after I figured out I had a 7450 processor)
export CFLAGS='-mtune=7450 -mcpu=7450 -fast -fPIC'and compile with --disable-pthread
and voila, a faster Ruby (not sure if the real reason was the compiler
flags, the pthread, or the updated version from p110 to p114, but
something helped it--I'm guessing it was the compiler options).