hirax.net::Keywords::「マルチスレッド」のブログ

■人間ベンチマーク　

　- PCが処理した内容をそのPCを使っているユーザーがー「処理」するところまでを含めたベンチマークテスト - というものをするべきじゃないか、とよく思う。「結局のところ人間が使う文房具代わりのPC」の使い勝手判断には、「PCが何かの処理をし終わるまでの時間」だけでなくて、「その結果を人間がさらに処理・判断するまでの時間」も含めたベンチマークを行うべきだと思うのである。

　例えば、100桁の何かの数字を「99秒の沈黙の後にいっきに表示するシステム」よりも「1秒に1桁の数字を順々に表示し、その結果100秒後に100桁の数字を表示し終わるシステム」の方が、その後の人間の処理も含めれば上に違いない、と思う。後のシステムであれば、その100秒経った瞬間には人間の処理もほぼ終わっているわけだからだ。前者のシステムであれば、99秒後にいきなり100桁表示されても人間がその数字を処理するにはさらに時間がかかるに違いないのである。だから、この場合「PCの処理時間」だけでベンチマークを行うのは「文房具のPC」としては間違いであると思うわけだ。

　人間の作業で例えるならば、「一人で黙々と作業を続けて、10日後にその作業の結果を他の人に見せる」よりも、「結局は作業自体に11日かかっても、1日毎に作業の経過を他の人に見せてている」場合の方が共同作業の中では良いことが多い、というのと同じだろう。

　で、なんでそんなことを思ったかというと、ゲームとかは別として、最近ではCPUの速度よりもメモリーの速度、メモリーの速度よりも人間の速度の方がボトルネックになることだって多いということを考慮に入れていない評価も多いんじゃないだろうか、と思ったのである。特に、マルチスレッドの評価、マルチCPUの評価、その辺りのハンドリングの評価、という辺りでそんなベンチマークの結果を特に知りたい今日この頃、なのである。

　ボトルネックになる人間の部分を以下に上手く気持ちよく動かせるかが一番重要だったりするのかも、と思ったりするのである。

■Rubyで「シリアル通信スレッドクラス」を作る　

　Rubyで「(Ｒｕｂｙシリアル通信ライブラリ（Windows用）TEXCELL を使った)シリアル通信スレッドクラス」を作りました。ソースコードとサンプルはここに置いておきます。”Microsoft Windows VISTAではほとんど見捨てられているような”シリアルポートでの送受信をRubyでスレッドを使って行うクラスです。Queueにデータを突っ込めば「シリアル通信スレッドクラス」から自動的に送信されます。また、受信した文字列が「（指定した改行コードで）一行になるたびに」receiveイベントが呼ばれるので(また、その際にQueueを指定しておけば受信行が自動的にそのQueueに追加されていきます)、読み込みのタイミング・必要な情報がまだ途中までしか読み込まれていない場合などの処理を気にすることなく使いたい、と考えながら作ってみた「シリアル通信スレッドクラス」です。
　たとえば、COM3で受信した内容をコンソールに出力するだけであれば、このようなコードで動くはずです。

require 'comThread'
receiveComThread=ComThread.new({:icomno=>3})
receiveComThread.start({:receive=>true, 
　　　　　　　　:receiveMonitor=>true})
sleep 60
receiveComThread.stop

  require 'comThread'
  q=Queue.new
  receiveComThread=ComThread.new({:icomno=>3,:rq=>q})
  sendComThread=ComThread.new({:icomno=>4,:sq=>q})
  receiveComThread.start({:receive=>true,
　　　 :receiveMonitor=>true})
  sendComThread.start({:send=>true})  
  sleep 60
  sendComThread.stop
  receiveComThread.stop

　以前、こんなことを書きました。

　「計測・解析ソフトウェア/ハードウェアのハック」が実験系技術者の一番のLifeHackかもしれない…と思っています。その思いを逆に言うならば、実験系技術者が費やす多くの時間を、計測・解析処理が消費していると思っているからです。そして、一番時間を消費している部分の高速化をすることが、全体の高速化に効果的だろう、と思っているわけです。

　そんなこんなで、何を今更…という、Perlで「シリアル通信とユーザインターフェース自動制御」のやり方を整理しておくことにしました。なぜかというと、経験的に(既成機器をを使わざるえないことが多い)「計測・解析ソフトウェア/ハードウェアのハック」は、シリアル通信制御とユーザインターフェース自動制御でほとんどの場合対応できる、からです。

■エクセルのマルチスレッド機能　

　Microsoft Excel 2007 を使っていると、前のバージョンとは違い、マルチスレッドの設定ができることに気がついたのです。そこで、試しに、以前遊んだ「エクセルでシミュレーション」シリーズのワークシートを使い、CPU数=1にした時とCPU数=2にした時の速度比較を行ってみました。「10×10ほどの小さな空間分割でポワソン方程式を差分法で解く」というワークシートで比較をしてみたのですが、計算時間にはまったく違いがみられませんでした。

　考えてみると、このワークシートの場合、セル間が循環参照されていて、単純に「独立に複数スレッドで(領域分割して)計算をする」というようなことはできそうにありません。これでは、マルチスレッド計算の効果が表れないのも、当然といえば当然です。

　そこで、次に、先ほどのワークシートを独立した２つの「10×10の空間」の電界計算をするものに変えてみました。といっても、つまりは、コピー＆ペーストして、２つの領域を作ってみただけです。今度は（マルチスレッド機能のCPU使用数の違いで）計算時間に差が出るかと思いきや、・・・CPUの数によらず、やはりどちらも35秒ほどで、マルチスレッドの効果は現れませんでした。

　「エクセルに深入りしたらおしまい」「エクセルは時間泥棒」と常々思っているのですが、「エクセルのマルチスレッド処理の動きがどのようになっているか」を調べたくてたまらないのです。もちろん、そんなことを始めたりしたら「時間がなくなる一方」になってしまうわけですが・・・。

■続 エクセル2007のマルチスレッド機能　

　エクセル2007のマルチスレッド機能について調べていると、こんな記事がありました。この記事に書かれている結果からは、マルチスレッド機能の効果は大きいように見えます。少なくとも、マルチスレッドか、シングルスレッドであるかの違いは大きいように思えます。

Time to recalculate MBRM UNIVOPT benchmark speed test spreadsheet

Test 1: Single core machine

Using Excel 2003 69.5sec.

Using Excel 2007 69.5sec.

Test 2: Dual-core machine

Using Excel 2003 88.97sec

Using Excel 2007 with 1 calculation thread 88.8sec.

Using Excel 2007 with 2 calculation thread 45.74sec.

Using Excel 2007 with 3 calculation thread 45.03sec.

　それでは試しに、というわけで「ベンチマーク for Excel 2000」で、マルチスレッド機能（CPU数=1 or 2）の違いを見てみました。その結果が下の２つのグラフ（の赤表示部分）です。上がマルチスレッド有効にした場合で、下がシングルスレッドの場合になります。スレッド数での違いは、やはりほとんど見られません。

　とはいえ、ファイル保存形式を変えてみても、エクセルのメニューバーには「互換モード」と表示されているのが気にかかるところです。もしかしたら、今回試してみた方法では、Excel　2007特有の機能は使われていないのかもしれません。

　・・・というわけで、やはり、エクセルに深入りすると、必ず恐怖の時間底無し泥沼が待っているような気持がしてきました。

■並列化テンプレートクラスライブラリ「Intel Threading Building Blocks」入門　

　「オープンソース化された並列化テンプレートクラスライブラリ「Intel Threading Building Blocks」入門」

　C/C++で並列アプリケーションを実装する手法として、並列化したい処理をOSのAPIを用いてマルチスレッド化する、もしくは並列プログラミングの規格である「OpenMP」を利用する、といったものが知られている。これらについては以前の記事でも紹介しているが、マルチスレッドを利用した実装は柔軟性がある一方で手間が掛かり、OpenMPは比較的手軽だが柔軟性に欠けるなど、それぞれに長所と短所がある。

　これらの問題を解決し、C++での見通しの良い並列処理実装を可能にするのが本記事で紹介する「Intel Threading Building Blocks」（以下、TBB）である。