[Ruby 1.9 - Feature #4607][Open] benchmark/bm vm3 thread mutex.rb の性能改善

Issue #4607 has been reported by Motohiro KOSAKI.


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

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

以下のような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 ともに劣化はなさそうなので入れてしまってもいいでしょうか?

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 ともに劣化はなさそうなので入れてしまってもいいでしょうか?

$B$^$D$b$H(B $B$f$-$R$m$G$9(B

In message “Re: [ruby-dev:43454] [Ruby 1.9 - Feature #4607][Closed]
benchmark/bm_vm3_thread_mutex.rb [email protected]=2~A1(B”
on Fri, 29 Apr 2011 10:17:26 +0900, Motohiro KOSAKI
[email protected] writes:

|$BE:IU$N$h$&$K%S%8!<%k!<%W$r(B100msec$B$N%?%$%`%"%&%HIU$-(Bcond_wait$B$KJQ$([email protected]$1$G!"$=$l$J$j$K2~A1$7$^$9!#(B
|
|1.8.7 1.106 sec
|1.9.3dev 109.064 sec
|w/ patch 16.331 sec
|
|make test-all, make benchmark
$B$H$b$KNt2=$O$J$5$=$&$J$N$GF~$l$F$7$^$C$F$b$$$$$G$7$g$&$+!)(B

$B$$$$$s$8$c$J$$$G$7$g$&$+!#(B

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs