From: Motohiro KOSAKI <kosaki.motohiro@...>
Date: 2011-04-29T10:17:26+09:00
Subject: [ruby-dev:43454] [Ruby 1.9 - Feature #4607][Closed] benchmark/bm_vm3_thread_mutex.rb の性能改善


Issue #4607 has been updated by Motohiro KOSAKI.

Status changed from Open to Closed
Assignee set to Motohiro KOSAKI
Target version set to 1.9.3

r31373

----------------------------------------
Feature #4607: benchmark/bm_vm3_thread_mutex.rb の性能改善
http://redmine.ruby-lang.org/issues/4607

Author: Motohiro KOSAKI
Status: Closed
Priority: Normal
Assignee: Motohiro KOSAKI
Category: core
Target version: 1.9.3


以下のようなmutexを取り合うプログラムが1.8.x と比べると1.9.xは有為に遅いです

bm_vm3_thread_mutex.rb
---------------------------------
require 'thread'
m = Mutex.new
r = 0
max = 1000
(1..max).map{
  Thread.new{
    i=0
    while i<max
      i+=1
      m.synchronize{
        r += 1
      }
    end
  }
}.each{|e|
  e.join
}
raise r.to_s if r != max * max
---------------------------------

1.8.7       1.106 sec
1.9.3dev  109.064 sec 

遅いだけで機能的には困らないのですが、さすがに1分超えるテストがあると 
make benchmark しるモチベーションが強烈に削られるので改善したいと思います。

され、遅い理由ですが。rb_mutex_lock()のlast_threadの判定にはraceがあります。lock_func()
に入ってGVLなしで走っている間はsleepにカウントされているので。かつlock_funcの中にはsched_yield()が
あるのもよくなくてスレッド数がCPU数超えてるときはここでpreemptionが起きる確率はかなり高いです。
で、last_threadだと判定するとビジーループをまわしつつrb_check_deadlock()を呼びまくる実装になっている
ので不必要なデッドロックチェックばかり走って肝心のロック保持スレッドがなかなか動けないので遅い。と

添付のようにビジーループを100msecのタイムアウト付きcond_waitに変えるだけで、それなりに改善します。

1.8.7       1.106 sec
1.9.3dev  109.064 sec 
w/ patch   16.331 sec

make test-all, make benchmark ともに劣化はなさそうなので入れてしまってもいいでしょうか？



-- 
http://redmine.ruby-lang.org