[#44036] [ruby-trunk - Feature #6242][Open] Ruby should support lists — "shugo (Shugo Maeda)" <redmine@...>

20 messages 2012/04/01

[#44084] [ruby-trunk - Bug #6246][Open] 1.9.3-p125 intermittent segfault — "jshow (Jodi Showers)" <jodi@...>

22 messages 2012/04/02

[#44156] [ruby-trunk - Feature #6265][Open] Remove 'useless' 'concatenation' syntax — "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>

45 messages 2012/04/06

[#44163] [ruby-trunk - Bug #6266][Open] encoding related exception with recent integrated psych — "jonforums (Jon Forums)" <redmine@...>

10 messages 2012/04/06

[#44303] [ruby-trunk - Feature #6284][Open] Add composition for procs — "pabloh (Pablo Herrero)" <pablodherrero@...>

57 messages 2012/04/12

[#44349] [ruby-trunk - Feature #6293][Open] new queue / blocking queues — "tenderlovemaking (Aaron Patterson)" <aaron@...>

10 messages 2012/04/13

[#44402] [ruby-trunk - Feature #6308][Open] Eliminate delegation from WeakRef — "headius (Charles Nutter)" <headius@...>

20 messages 2012/04/17

[#44403] [ruby-trunk - Feature #6309][Open] Add a reference queue for weak references — "headius (Charles Nutter)" <headius@...>

15 messages 2012/04/17

[#44533] [ruby-trunk - Bug #6341][Open] SIGSEGV: Thread.new { fork { GC.start } }.join — "rudolf (r stu3)" <redmine@...>

24 messages 2012/04/22

[#44630] [ruby-trunk - Feature #6361][Open] Bitwise string operations — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>

31 messages 2012/04/26

[#44648] [ruby-trunk - Feature #6367][Open] #same? for Enumerable — "prijutme4ty (Ilya Vorontsov)" <prijutme4ty@...>

16 messages 2012/04/26

[#44704] [ruby-trunk - Feature #6373][Open] public #self — "trans (Thomas Sawyer)" <transfire@...>

61 messages 2012/04/27

[#44748] [ruby-trunk - Feature #6376][Open] Feature lookup and checking if feature is loaded — "trans (Thomas Sawyer)" <transfire@...>

13 messages 2012/04/28

[ruby-core:44213] Re: Questions about thread performance (with benchmark included)

From: SASADA Koichi <ko1@...>
Date: 2012-04-09 05:46:31 UTC
List: ruby-core #44213
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

In This Thread