> I've just upgraded to Ruby 1.8.7 using MacPorts (ruby @1.8.7- > p72_1+thread_hooks) and while it runs flawlessly, the performance is > really really poor.
> I'm talking in comparison with the Ruby distro that ships with > Leopard, and with my previous installation of 1.8.6 also done with > MacPorts.
> For instance a bunch of rspecs i have take 6x to get executed, and ri > takes noticeably more time than previously to load any doc.
> Is anyone experiencing the same problem? Do you know how to fix it?
abc <arcadiorubiogar...@gmail.com> wrote: > I've just upgraded to Ruby 1.8.7 using MacPorts (ruby @1.8.7- > p72_1+thread_hooks) and while it runs flawlessly, the performance is > really really poor. > Is anyone experiencing the same problem? Do you know how to fix it?
The same problem reported at ruby-list-45593.(but Japanese only)
Summary is below. 1. On MacOS X(10.5.5), Ruby1.8.7(p72) compiled with --enable-pthread excute slowly, as Ruby use time of 70% at rb_call()->getcontext() in fib.rb
2. In MacPorts, ./configure with --enable-pthread option makes config.h using getcontext like below #define HAVE_GETCONTEXT 1 #define HAVE_SETCONTEXT 1
3. If you comment out these two lines, you will get normal speed Ruby1.8.7.
4. As Ruby1.9 don't use getcontext()/setcontext(), Ruby1.9 don't care --enable-pthread.
> On Sat, 1 Nov 2008 19:58:54 +0900 > abc <arcadiorubiogar...@gmail.com> wrote:
>> I've just upgraded to Ruby 1.8.7 using MacPorts (ruby @1.8.7- >> p72_1+thread_hooks) and while it runs flawlessly, the performance is >> really really poor.
Could someone explain this to to me. I checked the macports page a few days back and it said it disables/deletes -enable-pthreads due to some bug. So does that not mean that it's not there. As pointed above, it uses thread_hooks instead.
1. Is there any commandline option or other way of my ascertaining whether my install uses pthreads or not.
Another newb question:
2. One of the prev posts suggests altering config.h and running /configure. However, if one is using sudo port install how does one do this? I do not have a "configure" in my ruby folder and my config.h (/opt/local/var/macports/software/ruby/1.8.7-p22_3+darwin_9_powerpc+thread_ hooks/opt/local/lib/ruby/1.8/powerpc-darwin9.4.0/config.h) does not contain GETCONTEXT.
> Could someone explain this to to me. I checked the macports page a few > days back and it said it disables/deletes -enable-pthreads due to some > bug. So does that not mean that it's not there. As pointed above, it > uses thread_hooks instead.
apparently somebody said that the most recent macport of it now compiles with pthreads disabled.
> 1. Is there any commandline option or other way of my ascertaining > whether my install uses pthreads or not.
from [1] Maybe try with "ldd" on the ruby binaries--can't remember what the mac equivalent is but it exists.
> Another newb question:
> 2. One of the prev posts suggests altering config.h and running > ./configure. However, if one is using sudo port install how does one do > this? I do not have a "configure" in my ruby folder and my config.h > (/opt/local/var/macports/software/ruby/1.8.7-p22_3+darwin_9_powerpc+thread_ hooks/opt/local/lib/ruby/1.8/powerpc-darwin9.4.0/config.h) > does not contain GETCONTEXT.
If you install it from source you should be able to get at it right...not sure using macports.
> btw, will installing 1.9 from macports create a separate executable > such > as ruby1.9 so we can run 8 and 9 in parallel. Or overwrite?
The ruby19 Portfile sets the --program-suffix argument of configure to 1.9, so yes you could install Ruby 1.8 and Ruby 1.9 at the same time on the same machine.
That was really helpful information. I digged a bit more based upon that thread, and for those who compile Ruby 1.8.7 from source on OS X, here's a more handy way: add 'ac_cv_func_getcontext=no ac_cv_func_setcontext=no' along with --enable-pthread, e.g.: ./configure --enable-pthread --enable-shared ac_cv_func_getcontext=no ac_cv_func_setcontext=no
Then the following lines won't appear on your config.h: #define HAVE_GETCONTEXT 1 #define HAVE_SETCONTEXT 1
Just my 2 cents, Jason
On 11月3日, 下午6时01分, nakatani katsumi <al...@kcat.zaq.ne.jp> wrote:
> abc <arcadiorubiogar...@gmail.com> wrote: > > I've just upgraded to Ruby 1.8.7 using MacPorts (ruby @1.8.7- > > p72_1+thread_hooks) and while it runs flawlessly, the performance is > > really really poor. > > Is anyone experiencing the same problem? Do you know how to fix it?
> The same problem reported at ruby-list-45593.(but Japanese only)
> Summary is below. > 1. On MacOS X(10.5.5), Ruby1.8.7(p72) compiled with --enable-pthread excute slowly, > as Ruby use time of 70% at rb_call()->getcontext() in fib.rb
> 2. In MacPorts, ./configure with --enable-pthread option makes config.h using getcontext > like below > #define HAVE_GETCONTEXT 1 > #define HAVE_SETCONTEXT 1
> 3. If you comment out these two lines, you will get normal speed Ruby1.8.7.
> 4. As Ruby1.9 don't use getcontext()/setcontext(), Ruby1.9 don't care --enable-pthread.
Jason Lai <ja...@jasonlai.net> wrote: > Hi Nakatani-san,
> That was really helpful information. I digged a bit more based upon > that thread, and for those who compile Ruby 1.8.7 from source on OS X, > here's a more handy way: add 'ac_cv_func_getcontext=no > ac_cv_func_setcontext=no' along with --enable-pthread, e.g.:
Oh,I missed to follow this problem. This bug was fixed with 1.8.7-p72_2 of MacPorts, that was reported at ruby-list:45621(japanese only). (ruby 1.8.7-p72_1 of MacPorts has bug) You can use the most up-to-date ruby of MacPorts without any extra option.
> Jason Lai <ja...@jasonlai.net> wrote: > > Hi Nakatani-san,
> > That was really helpful information. I digged a bit more based upon > > that thread, and for those who compile Ruby 1.8.7 from source on OS X, > > here's a more handy way: add 'ac_cv_func_getcontext=no > > ac_cv_func_setcontext=no' along with --enable-pthread, e.g.:
> Oh,I missed to follow this problem. > This bug was fixed with 1.8.7-p72_2 of MacPorts, that was reported at > ruby-list:45621(japanese only). > (ruby 1.8.7-p72_1 of MacPorts has bug) > You can use the most up-to-date ruby of MacPorts without any extra option.
|
