ruby is slow because of --enable-pthreads

[Brian Takita]

Binary package hint: ruby

The Ruby package is compiled with the --enable-pthreads option. This has been known to drastically slow down the interpreter by ~ 50%. The effect of this is that Ruby on Windows outperforms Ruby on Ubuntu.

--enable-pthreads is generally not used within the Ruby community.

http://antoniocangiano.com/2008/12/10/reflections-on-the-ruby-shootout/

[Brian Takita (brian-takita)]

Until there is action on this, the "best practice" will be to compile ruby from source, and not use this package, when using Ubuntu.

[Lucas Nussbaum (lucas)]

Please provide a reproducible test case, not just FUD.

I'm closing the bug, feel free to reopen when you can provide more info.

[Lucas Nussbaum (lucas)]

reassigning to ruby1.8

[Brian Takita (brian-takita)]

I provided a link to a benchmark.

The way to reproduce this issue is to run
sudo apt-get install ruby
ruby benchmark.rb

Compare the results with a compiled version of ruby:

wget ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz
tar zxvf stable-snapshot.tar.gz
cd stable-snapshot
./configure
make
sudo make install

ruby benchmark.rb

As in the benchmark link I provided, you will see that the compiled version of ruby is much faster.

[Brian Takita (brian-takita)]

Sorry, to get the compiled version of Ruby, use the following instruction instead:

wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p72.tar.gz
tar zxvf ruby-1.8.7-p72.tar.gz
cd ruby-1.8.7-p72
./configure
make
sudo make install

[Brian Takita (brian-takita)]

If you are interested in using the Ruby benchmark suite, you can get it at:

http://github.com/acangiano/ruby-benchmark-suite/tree/master
git clone git://github.com/acangiano/ruby-benchmark-suite.git

[Brian Takita (brian-takita)]

I also used google to find some other people having issues with --enable-pthreads.

http://www.google.com/search?q=ruby+enable-pthreads&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a31872d447e867cb/40a92a28e9e03793?pli=1
http://blogs.sun.com/prashant/entry/ruby_and_enable_pthreads

[Lucas Nussbaum (lucas)]

When building without --enable-pthread:
compiling tk
*****************************************************************************
**
** PTHREAD SUPPORT MODE ERROR:
**
** Ruby is not compiled with --enable-pthread, but your Tcl/Tk
** library seems to be compiled with pthread support. This
** combination may cause frequent hang or segmentation fault
** errors when Ruby/Tk is working. We recommend that you NEVER
** create the library with such a combination of pthread support.
**
** Please recompile Ruby with the "--enable-pthread" configure option
** or recompile Tcl/Tk with the "--disable-threads" configure option.
**
*****************************************************************************

So, the two options are:
(1) live with the performance penalty, keep --enable-pthread, close the bug
(2) ignore the warning (which prashant's blog recommends), and compile without --enable-pthread

We could maybe test (2) now in Ubuntu Jaunty, and see if bug reports start popping up. What do you think?

[Lucas Nussbaum (lucas)]

I spoke too fast. removing --enable-pthread disables the build of ruby-tk and causes a build failure later in the process:
dh_movefiles -plibtcltk-ruby1.8 \
     usr/lib/ruby/1.8/x86_64-linux/tcltklib.so \
     usr/lib/ruby/1.8/x86_64-linux/tkutil.so
dh_movefiles: debian/tmp/usr/lib/ruby/1.8/x86_64-linux/tcltklib.so not found (supposed to put it in libtcltk-ruby1.8)
dh_movefiles: debian/tmp/usr/lib/ruby/1.8/x86_64-linux/tkutil.so not found (supposed to put it in libtcltk-ruby1.8)
tar: /home/lucas/dev/pkg-ruby/ruby1.8/build-area/ruby1.8-1.8.7.72/debian/movelist: Cannot stat: No such file or directory
tar: Error is not recoverable: exiting now
tar: This does not look like a tar archive
tar: Error exit delayed from previous errors

Doesn't sound like a regression we can live with.

[Lucas Nussbaum (lucas)]

I built ruby1.8 with the following patch:
--- debian/rules (revision 201)
+++ debian/rules (working copy)
@@ -39,7 +39,6 @@
  DEB_CONFIGURE_USER_FLAGS += --with-extra-search-path='/usr/lib/ruby/$(ruby_ver)/i386-linux'
 endif
 DEB_CONFIGURE_USER_FLAGS += --program-suffix=$(ruby_ver)
-DEB_CONFIGURE_USER_FLAGS += --enable-pthread
 DEB_CONFIGURE_USER_FLAGS += --enable-shared
 DEB_CONFIGURE_USER_FLAGS += --enable-ipv6
 DEB_CONFIGURE_USER_FLAGS += --with-lookup-order-hack=INET
@@ -54,6 +53,7 @@
 DEB_CONFIGURE_USER_FLAGS += --with-bundled-sha1
 DEB_CONFIGURE_USER_FLAGS += --with-bundled-md5
 DEB_CONFIGURE_USER_FLAGS += --with-bundled-rmd160
+DEB_CONFIGURE_USER_FLAGS += --disable-tcl-thread

 DEB_MAKE_BUILD_TARGET = all test
 #DEB_MAKE_BUILD_TARGET = all test test-all

It built fine, but when loading tk:
irb(main):002:0> require 'tk'
/usr/lib/ruby/1.8/tk.rb:1127: warning: Inconsistency. Loaded Tcl/Tk libraries are enabled nativethread-support. But `tcltklib' is not. The inconsistency causes SEGV or other troubles frequently.
=> true
irb(main):003:0>

It seems that the only option would be to drop ruby-tk support.

[Harald Sitter (apachelogger)]

Honestly, I think it is better to have a product that is missing functionality (especially since the GUI tookit feature is provided through 3rd party [i.e. not upstream ruby] implementations of Qt and GTK+ bindings) than a product that is so incredibly slow that anyone who wishes to use it in sensible matter is kind of forced to build it from source without pthreads.

Since one of Ruby's primary use cases is Rails it is all the more important to have it work at sensible speed (promoting the Ubuntu server stack and all).

[Harald Sitter (apachelogger)]

Oh, almost forgot :)
openSUSE ain't got no tk:
http://rpm.pbone.net/index.php3/stat/6/idpl/11099074

Fedora does have tk though:
http://cvs.fedoraproject.org/viewvc/devel/ruby/ruby.spec?view=markup
Wasn't able to find a speed but in the RH bugzilla though (then again when asking google for ruby compiled from source, the first hit is about how to do that on RH :D)

[Brian Takita (brian-takita)]

I'd say drop tk support. I don't know anybody who uses it. (99%-1% rule is probably in effect here).

I would also say that the onus is on the ruby-tk developer to make it compatible without --enable-pthreads.

[Dan Peterson (dpiddy)]

I recommend the patch to configure.in described/linked here be applied:

http://timetobleed.com/fix-a-bug-in-rubys-configurein-and-get-a-30-performance-boost/

It will fix the pthread slowness while keeping tk happy.

[Nigel Kersten (nigelk)]

According to Matz, this is no longer an issue in Ruby 1.8.7

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/23583

yet I'm still seeing performance improvements in general with the ruby benchmark suite when applying the configure.in patch from timetobleed.com against 1.8.7 from Karmic.

[Dan Peterson (dpiddy)]

What

[Dan Peterson (dpiddy)]

Argh, sorry. What's the reasoning for this update? As far as I can tell the patch would still be beneficial with the current 1.8.7 patchlevel.

[Dan Peterson (dpiddy)]

Created upstream bug: http://redmine.ruby-lang.org/issues/show/2553

[Lucas Nussbaum (lucas)]

Anyway, my position is still that this should be upstreamed first. I'm not going to add that patch to the Debian (or Ubuntu) package if upstream doesn't want to add it themselves.

Marking the bug as In Progress to reflect the fact that we are waiting for a decision from upstream.

[bronto (mmarongiu)]

I'd add my 0.02.

Maybe you could provide two different packages for ruby, the current "stock" version and another one compiled with --disable-pthreads?

I've just filed this wishlist entry to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579229

Ciao
--bronto

[Brian Takita (brian-takita)]

Another possibility is to use Ruby Enterprise Edition. I use it now and I love it. So far there have not been any compatibility issues.

They even have a deb package.
http://www.rubyenterpriseedition.com/download.html

Even though they say it's for 8.04, it works on 9.04, 9.10, and 10.04.

[Brian Takita (brian-takita)]

Basically REE is Ruby 1.8.7 but MUCH faster. It doesn't do pthreads, supports copy-on-write when forking, optimizes threading, etc. It also "takes over" ruby, which IMO is a plus.

The other nice thing is it does not need to be officially maintained by debian, so politics won't factor in here. It would be nice if debian maintained it, however I trust the folks at Phusion more then debian when it comes to maintaining Ruby. :-)

[Lucas Nussbaum (lucas)]

Brian, please stop being such an asshole. You are totally free to use REE, but then don't come here spamming the ruby1.8 bug reports with insults to the Debian Ruby maintainers (I am one of those, btw).

[Brian Takita (brian-takita)]

Your right, that last quip was uncalled for.

I do want a good solution, however, it seems the ruby & debian community are often at odds. I somewhat understand why it is so difficult to reconcile.

Ruby uses rubygems, which work great btw. Ruby has lots of different types of packages and versions. Things in Ruby move fast and debian is all about stability. The culture and processes are vastly different. What I meant by "trusting Phusion more", is Phusion part of the Ruby culture and thus more compatible with most Ruby development. I don't want to be locked into the debian world when it comes to Ruby. Everything else, I'm happy to be in the debian world.

The thing I'm worried about is that I do not use the ubuntu/debian ruby stack at all, because it simply does not do what I want it to do. I can't use it. I'm sorry, but that is the truth. I think that a number of other developers agree with me too.

Using the REE package is not a slight for the maintainers of the Ruby package. MRI is slow, and REE fixes some of the slowness. I just wanted to share because others may want a faster version of Ruby that is .deb packaged.

This probably is the wrong forum for this discussion. I'm happy to take it elsewhere if you wish to continue.

Maybe RVM (Ruby version manager) will be a good solution. You can have a RVM package using the ruby with --enable-pthreads to keep compatibility with tk, and have a streamlined version of ruby (no pthreads MRI or REE) for general development. Maybe a rule that the number of packages that depend on the streamlined version of ruby should be limited?

[Brian Takita (brian-takita)]

> I don't want to be locked into the debian world when it comes to Ruby.

Not to say that the debian process cannot be improved. It certainly can. PPA's work great, for example. Maybe a PPA can be part of the solution.

[Lucas Nussbaum (lucas)]

On 26/04/10 at 18:03 -0000, Brian Takita wrote:
> > I don't want to be locked into the debian world when it comes to Ruby.
>
> Not to say that the debian process cannot be improved. It certainly can.
> PPA's work great, for example. Maybe a PPA can be part of the solution.

PPAs are not available for Debian. Canonical management said they didn't
have the resources to provide it. And on the Debian side, we apparently
don't feel that it is too important, since we already have Debian
experimental to provide packages that are not really ready for Debian
unstable.
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

[Lucas Nussbaum (lucas)]

On 26/04/10 at 17:54 -0000, Brian Takita wrote:
> I do want a good solution, however, it seems the ruby & debian community
> are often at odds. I somewhat understand why it is so difficult to
> reconcile.

Some people on the Ruby side like to throw fuel on the fire, which
doesn't help. But in general, I think that we have a pretty good
understanding of our disagreements. The situation is very complex, and
users always seem to think that there's a simple solution. But it's easy
to solve 80% of the problems, very much harder to solve the remaining
20%.

> The thing I'm worried about is that I do not use the ubuntu/debian ruby
> stack at all, because it simply does not do what I want it to do. I
> can't use it. I'm sorry, but that is the truth. I think that a number of
> other developers agree with me too.

On the other hand, lots of people are not that unhappy with the state of
Ruby in Debian/Ubuntu.

> Using the REE package is not a slight for the maintainers of the Ruby
> package. MRI is slow, and REE fixes some of the slowness. I just wanted
> to share because others may want a faster version of Ruby that is .deb
> packaged.

It would be better if the energy spent on REE would be spent on
improving Ruby 1.8 or 1.9... But anyway. There are currently plans to
provide a way to support several ruby versions at the same time, with
all the libraries available for all implementations. It might make sense
to package REE at this point (or just apply the patches to a special
ruby1.8 build).

> Maybe RVM (Ruby version manager) will be a good solution. You can have a
> RVM package using the ruby with --enable-pthreads to keep compatibility
> with tk, and have a streamlined version of ruby (no pthreads MRI or REE)
> for general development. Maybe a rule that the number of packages that
> depend on the streamlined version of ruby should be limited?

Are you aware that RVM messes with your .bash* to achieve what it wants
to do?
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

[Mark Carey (dj-mook)]

Lucas Nussbaum wrote on 2010-04-27:
> On the other hand, lots of people are not that unhappy with the state of
> Ruby in Debian/Ubuntu.

Argument from silence doesn't really hold much weight. The pthreads issue is longstanding known issue in the ruby community. The refusal of ubuntu to address it caused many ubuntu users to go build our own ruby, which I've done on any system where I cared about ruby performance for the last 3 years or so. I'm only speaking up now because I'm trying to be a better community member, what ever that means.

> It would be better if the energy spent on REE would be spent on
> improving Ruby 1.8 or 1.9... But anyway.

Actually all of the patches were submitted back upstream, but ruby-core are very slow to move.

> There are currently plans to
> provide a way to support several ruby versions at the same time, with
> all the libraries available for all implementations. It might make sense
> to package REE at this point (or just apply the patches to a special ruby1.8 build).

I'm very much in favor of this. Although at the moment, REE is only a ruby 1.8.7 alternative, not 1.9. The difference tho for memory usage between REE & MRI 1.8.7 is striking. The current deb's provided by phusion for REE install the ruby binaries to /usr/local, which may or may not be a problem for other users consuming them.

> Are you aware that RVM messes with your .bash* to achieve what it wants to do?

Considering that it gives you the ability to do things like gemsets, project specific configuration, I think the tradeoffs far outweigh the risks.

Besides I dump all the default ubuntu .bash* tweaks anyway, and rvm works fine with what I use, and hasn't caused any problems to date.

Further rvm allows to manage ruby for each user without the need for elevated privileges, which is quite nice for a number of reasons.

[Lucas Nussbaum (lucas)]

On 10/06/10 at 21:22 -0000, Mark Carey wrote:
> Lucas Nussbaum wrote on 2010-04-27:
> > On the other hand, lots of people are not that unhappy with the state of
> > Ruby in Debian/Ubuntu.
>
> Argument from silence doesn't really hold much weight. The pthreads
> issue is longstanding known issue in the ruby community. The refusal of
> ubuntu to address it caused many ubuntu users to go build our own ruby,
> which I've done on any system where I cared about ruby performance for
> the last 3 years or so. I'm only speaking up now because I'm trying to
> be a better community member, what ever that means.
>
> > It would be better if the energy spent on REE would be spent on
> > improving Ruby 1.8 or 1.9... But anyway.
>
> Actually all of the patches were submitted back upstream, but ruby-core
> are very slow to move.

Could you point to the redmine bugs describing the patches?
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

[Dan Peterson (dpiddy)]

This is the one I opened:

http://redmine.ruby-lang.org/issues/show/2553

I need to do that verification but a quick look at the configure.in history in the 1.8.7 branch doesn't show anything interesting recently related to ucontext or pthreads.

[Andre Nathan (andre-digirati)]

A fix has been commited to the upstream repository recently:

http://redmine.ruby-lang.org/repositories/diff/ruby-18/configure.in?rev=28404

This shouldn't require any changes to the ./configure options, just a rebuild of the package. It would be great if the fix could be added to the Debian/Ubuntu package too.

Best regards,
Andre

[Launchpad Janitor (janitor)]

This bug was fixed in the package ruby1.8 - 1.8.7.299-2

---------------
ruby1.8 (1.8.7.299-2) unstable; urgency=low

  * Convert from dpatch to quilt using dpatch2quilt.sh
  * Add patch 100730_disable_getsetcontext_on_nptl: disable getsetcontext on
    NPTL. LP: #307462, Closes: #579229
  * Added 100730_verbose-tests.patch: run tests in verbose mode.
  * Run make test-all, but do not consider failures fatal for now.
  * Upgrade to Standards-Version: 3.9.1. No changes needed.
  * Deal with Ubuntu changing the GCC target to i686-linux-gnu: search
    for libs in i486-linux too. LP: #611322.
 -- Lucas Nussbaum <email address hidden> Fri, 30 Jul 2010 17:45:14 -0400

[Dan Peterson (dpiddy)]

Also fixes #317206?

Thanks for sticking with this!

[Lucas Nussbaum (lucas)]

On 31/07/10 at 18:51 -0000, Dan Peterson wrote:
> Also fixes #317206?
>
> Thanks for sticking with this!

Yes! Marked as Fix Released.
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

[Robbob (rob-kirkbride)]

Will this be included in Lucid?

[Lucas Nussbaum (lucas)]

as a backport, maybe. but it clearly requires more testing before.