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

Em 27-03-2012 23:22, Tomoyuki Chikanaga escreveu:
> Hello, Rodrigo.
>
> To be honest, I'm not familiar very much with JRuby,
> but I've heard that on JRuby Thread can be executed truly parallel.
> On the other hand, MRI has GVL and cpu bounded calculation could be
> executed only concurrently, I means threads share a cpu core with time slicing.
> So if there're many cpu cores in your environment, cpu bounded multi
> threaded code
> might be executed faster on JRuby than on MRI.
>
> I'm afraid I might misunderstand the point.
> I hope someone expert at JRuby/MRI give a more correct comment.

Hi Tomoyuki, thank you for your response.

Actually I have already read about this in some sites but I never found 
an official documentation about threads behavior in MRI.

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

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.

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...

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.

Kind regards,
Rodrigo.