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

Hi.

On 2012年04月09日 22:37, Rodrigo Rosenfeld Rosas wrote:
> Hi Urabe, thank you for your input, but I think you have over-simplified. Read my inline comments.
> 
> Em 09-04-2012 04:24, Urabe Shyouhei escreveu:
>> #### MRI threads myths and facts #####
>>
>> Myth1: "Forking processes to run parallel wastes memory"
>>
>> The fact is, no.  You can waste memories if you wish, but that is also
>> true for threading.  With a  careful implementation a process is quite
>> small in  memory consumption.   If you are  in doubt, see  how unicorn
>> forks its child processes.
> 
> Yes, you're right, there are better ways of using multiple processes (through forking) without wasting too much memory like the common proxied solution.
> 
> But then you have another problem. Suppose you want to benchmark your application against multiple Ruby implementations. You'd have to create your own "parallel" methods that would be specific for each Ruby implementation. For example, forking in JRuby is terribly slow.

Yes.  This  is a headache.  I hope  there is a reasonable  set of APIs
that both MRI and JRuby (and others) can implement efficiently.

>> Myth2: "Threading boosts your application performance"
>>
>> This is also no.  Multi-threaded programming is _very_ difficult to do
>> properly.  And  if you  do it badly,  its performance gets  even worse
>> than a  single threaded one.   A multi-threaded application  that does
>> scale can also scale much easily by using processes.
> 
> This is not a myth. This entire thread was born from a real issue:
> 
> http://rosenfeld.herokuapp.com/en/articles/ruby-rails/2012-03-04-how-nokogiri-and-jruby-saved-my-week
> 
> Multi-thread is not always difficult and being difficult doesn't mean it can't be implemented in a more performant way.

Yes, using JRuby was one of  the easiest approach for you.  Said that,
I still believe  it is possible to fork your  process to fully utilize
your  multi-core  machine.  Your  problem  needed parallel  execution;
fully  multi-threaded paradigm (such  as interaction  between threads)
was not required, was it?

>> Myth3: "Threading is the way to go"
>>
>> This is  quite doubtful.  Multi-threaded programming  is too difficult
>> to  develop, almost  impossible to  debug,  and normally  do not  work
>> properly.   Multi-threading  is too  easy  to  fail.  Some  restricted
>> model, such  as Shared Nothing  architecture, seems to have  much more
>> potential.
> 
> People have been doing multi-threaded programs for decades and while certainly there can be bugs hard to track on threaded applications who said that programming was supposed to be easy? Sometimes some solutions require a more complicated approach.

We _want_  to make it  easy.  For instance  in Ruby you don't  have to
care about  malloc/free counterbalance.  You don't have  to care about
manipulating  struct sockaddr_storage.   Then why  you have  to bother
mutex dead-locks?

I want you, programmers, to code happily. I believe a language can let
you do so.  Does a  parallel-execution really make you happy?  Doesn't
it give you more pain than gain?

> I agree that Shared Nothing architectures can be interesting too, but choosing some solution architecture should be the programmers decision in my opinion.

We are not going to deprecate Threads that we already have.  If we add
SN-architecture  to our  core, that  should  be an  opt-in.  So  don't
worry, you can decide your architecture.  I promise.

>> Myth4: "We are ignoring Rais"
>>
>> Definitely no.
>>
>> Myth5: "You can make MRI lock-free"
>>
>> Do it yourself if you think so.  Patch welcomed.
> 
> I don't think any threaded application can be lock-free, including a language interpreter. But having locks (instead of a single global lock) doesn't mean you can't use the full power of processors.

Technically  speaking, there  are  reasons why  MRI  cannot take  this
approach.  One  reason for it is  that MRI's GC needs  a giant locking
because no  modifications to  any objects shall  be allowed  during GC
(this restriction can theoretically be weakened, but in practice it is
very hard).  Another  reason is that most extension  libraries are not
designed to  be multi-thread ready;  for instance the  SQLite database
does  not  support  multiple  transactions  per  a  connection,  which
effectively kills multi-threaded usage.
cf: http://www.sqlite.org/faq.html#q6
 
> Unfortunately I don't have time nor skills for patching CRuby even for much easier patches... :( Maybe in the future...
> 
> I was just stating that I don't think someone with skills has invested much time trying to do so either because they don't think CRuby could benefit from parallel processing that much.
> 
> That is what I'm trying to get them to reflect about this situation when I launched this thread. If they agree that parallel threading can be very useful, than it would be clear that the only reason for CRuby not supporting it is the fact that it is currently difficult to patch Ruby to get rid of the global lock approach.

Someone with skills is always welcomed!

> Cheers,
> Rodrigo.