From: SASADA Koichi <ko1@...>
Date: 2012-04-09T14:46:31+09:00
Subject: [ruby-core:44213] Re: Questions about thread performance (with benchmark included)

Hi,

(2012/03/28 21:51), Rodrigo Rosenfeld Rosas wrote:
> Actually I have already read about this in some sites but I never found
> an official documentation about threads behavior in MRI.

I can say "It is true.  Ruby 1.9 does (and 2.0 will) not run threads in
parallel".

> It seems that due to some global lock we can't get code to run
> concurrently in CPU intensive applications.

One global lock.  We can run threads *concurrently*.

Terminology:
  Concurrent: run multiple activities in logical (time sharing, etc).
  Parallel: run multiple activities simultaneously in physical.

> I mean, threads are useless for those kind of applications. It seems
> that threads in MRI are only useful for IO intensive applications or
> some evented based applications.

Basically, yes.

> This is really a blocker issue for those willing to do intensive
> calculations that will prevent them from using MRI and having to sort to
> JRuby or other language for the job.
>
> I hope this will change for MRI at some point...

Parallel threading have several problems, for example, debugging issue
and single performance issue.  Because of these issues I want to prepare
another solution.

> Specially for web servers this behavior leads to bad design from some
> web frameworks that are optimized to be used with MRI.
> 
> For example, Rails common deploy strategy is to use multiple processes
> for dealing with concurrent requests, which will use much more memory
> than would be required with a threaded environment.
> 
> This is specially an issue if you're paying a VPS with prices varying by
> available RAM.
> 
> I think this strategy is the common one only for Ruby applications
> (except from JRuby which doesn't have this limitation).
> 
> This is totally weird and I guess most frameworks would have their
> design changed to be optimized for threads usage if threaded code could
> be run concurrently in CRuby.
> 
> I don't think Ruby should ignore the fact that its current huge
> popularity has came from the Rails framework and there are lots of
> people willing to use it for web development, so it shouldn't be
> considered as a second-class citizen.
> 
> The most important limitation for CRuby nowadays is this lack of
> concurrent threads code in my opinion. This is a blocker for the correct
> deploy strategy.
> 
> For example, you're currently not allowed to write long-polling
> applications with CRuby and Rails because each long-polling request
> would require a different process.
> 
> Well, actually in this case you can use threads because this would fall
> in the evented based category, but if you have some report action that
> needs lots of computation it won't be able to compute the results faster
> by using multiple cores.
> 
> Are there any plans for changing this situation? Most servers will have
> more than 6 cores and they won't be used in full capacity for CRuby
> applications nowadays.

No.

-- 
// SASADA Koichi at atdot dot net