徒然Ruby（４０）スレッドが意外に遅い

Fiberを書いたときから、次はスレッドを書こうと思っていましたが、時間がかかってしまいました。その理由は、期待したとおりのスレッドの効果がなかったためです。今回はそのことを書きますが、これはRubyのスレッドの抱えている問題なのか、自分のやり方が悪いのかははっきりしていません。

スレッドの基本
Threadクラス
スレッドが有効なケース
ファイルの読み込み
コマンドの受付をスムーズに行う
結論

スレッドの基本

スレッドとは

並行して走るプログラムで、Rubyの場合は「プログラム」はブロックになる
ひとつのプロセス内で複数のメソッドが並行して動き、プロセスをまたいでメソッドが動くことはない
Rubyの場合は一度にはひとつのメソッドしか動かない（例外有り）。複数のメソッドが交代で動くイメージ

Rubyには子プロセスを立ち上げる機能もあります。それを使うと2つのプログラムが同時に動くことができます。現在は複数コアのCPUがほとんどなので、まさに同時です。それぞれのプログラムが関連することなく切り分けられれば、複数プロセスが最速になります。

Threadクラス

RubyではThreadクラスでスレッドを生成します。次の例では最初のスレッドがaからzまでを画面に出力、2番めのスレッドが100から200までを画面に出力します。スレッドは途中で切り替わるので、アルファベットと数字が混在して出力されます。

def ax100200
  t1 = Thread.new {("a".."z").each {|c| print "#{c}\n"}}
  t2 = Thread.new {(100..200).each {|x| print "#{x}\n"}}
  t1.join
  t2.join
end

Thread.newのブロックがひとつのスレッドになる。newメソッドの返り値はスレッドオブジェクトになる
このプログラムにはスレッドが3つあり、t1、t2とメインスレッド（最初に動くプログラム自身）がある
メインスレッドが終了すると、子孫メソッドも強制的に終了させられる。それを避けるには、メインスレッドを無限ループにするか、joinメソッドで子孫メソッドの終了を待つようにする。上記のプログラムでは、t1.joinでt1の終了までメインプログラムが待つようになり、t1の終了で再開の後にt2.joinでt2の終了を待つようになる

joinメソッドのタイミングは重要で、仮にt2生成の前にt1.joinしてしまうと、t1の終了後にt2が生成されることになり、並行には動いていないことになります。

スレッドが有効なケース

Rubyのスレッドは一度にはひとつのスレッドしか動かないので、CPUで大量の計算をするようなプログラムをスレッドにしても時間短縮にはなりません。しかし、CPUに待ち時間があり、その間他のスレッドを実行することにより、全体の実行時間を短縮することは期待できます。

I/OはCPUに比べ低速なので、I/O待ちのあるプログラムに使う
同様に通信もCPUに比べて低速なので、通信待ちのあるプログラムに使う。例えばダウンロードを別プロセスにするなど

これ以外に、同時に2つのものが動くような事象をプログラム化するときにはスレッドが向いています。例えば点Aを点Bが最短で追跡するとき、Aの動きとBの動きをシミュレートするなどが考えられます。ただ、スレッドの切り替わりをスレッド自身がコントロールできないので、シミュレーションは完全なものにはなりませんが。そのモデルによりますが、ファイバーのほうが良い場合もありえます。

以上の考察に基づき、プログラムを試してみました。その結果ははたして・・・・？

ファイルの読み込み

ファイルの読み込みには時間がかかるから、マルチスレッドにすれば速いのではないか？実際にやってみました。

def s_read(files)
  files.each {|f| File.read(f)}
end

def c_read(files)
  threads = []
  files.each do |file|
    threads << Thread.new(file) {|f| File.read(f)}
  end
  threads.each {|t| t.join}
end

def s_or_c_input
  files = Dir.glob("_example/*.rb")

  t1 = Time.now
  s_read(files)
  t2 = Time.now
  p t2 - t1

  t1 = Time.now
  c_read(files)
  t2 = Time.now
  p t2 - t1
end

s_or_c_input

s_readがスレッドなしのシーケンシャル（一列に並んだ）に読み込むメソッド、c_readがコンカレント（同時並行）な読み込みのプログラムです。実行してみると

$ ruby _example/example40.rb
0.011881702
0.034613109
$ ruby _example/example40.rb
0.000459287
0.034651356

なんと、シーケンシャルの方が速い。しかも2回めは圧倒的な差に広がっています。

ということは、メソッドの生成にかかる時間が大きく影響しているのではないでしょうか。また、2回目で大差になったのは読み込みにおけるキャッシュの効果ではないかと思いました。

書き込みではどうかと思い、実験しましたが、そちらもシーケンシャルの方が速かったです。 2回行うと、2回めの方が差が開きました。書き込みにおいてもキャッシュの効果が出たようです。

コマンドの受付をスムーズに行う

コマンドを受け付けて、それに対応する処理をする場合、処理時間が長いと次の受付までの待ち時間が発生します。それをスレッドを使うことによって待たずに済むようにすることができます。

Readlineクラスを使ってやってみました。

require "readline"

def rl
  threads = []
  # If the input is EOF (ctrl-d), Readline.readline returns nil.
  while buf = Readline.readline("> ", false)
    i = buf.to_i
    if 1 <= i && i <= 9
      threads << Thread.new(i) do |n|
        x = (1..(n*100000000)).inject {|a,b| a+b}
        File.open("tempfile","a") {|file| file.print("#{x}\n")}
      end
    end
  end
  threads.each {|t| t.join}
end

rl

目論見通り処理を待たずに次のプロンプトが出るのですが、マルチスレッドの影響でreadlineのプロンプトに乱れが出ました。ちかちかしたり、プロンプトが2個でたりします。 readlineはスレッド対応しているとのことなので、原因は良くわかりませんでした。終了させるにはCtrl-Dを押します（Linuxの場合）。それはreadlineにはEOF（end-of-file）となって伝わり、readlineメソッドがnilを返してループを抜けることができます。しかし、子メソッドの終了を待つので、プログラム全体の終了には時間がかかります。これは高速化とはいえません。

結論

Rubyのスレッドは時間がかかるので、効果があるようなケースを見つけて使うことになると思います。おそらくサーバ関係のプログラムでは効果を発揮すると思います。また、ダウンロードやバックアップをバックグラウンドでやるのも効果がありそうです。普段のちょっとしたプログラムでは使いそうもないな、というのが実感でした。

おもこん

おもこんは「思いつくままにコンピュターの話し」の省略形です