【最初の注意】
本記事は、私が2002年当時に今はなき「XWIN II Web Page」で掲載したものを、基本的にそのままの形で再掲載したものです。では、どうぞ。
この前の記事「マルチスレッドでのHyper-Threading ── TMPGEnc編 II」
巻頭言 979 「Hyper-Threadingの有用性──Super πとTMPGEnc同時実行」
さて、今回の巻頭言は繰り延べとなっているTMPGEnc 2.02とSuper πを同時実行させながら、Hyper-Threadingテクノロジの有用性を探っていくことにしよう。
と、これを行う前に、これまでの簡単な復習──というほどのものではないが、これまでのSuper π及びTMPGEncにおけるテスト結果から導出されるHyper-Threadingの特長についてふれておくことにする。
Super πのようなシングルスレッドアプリケーションでは、基本的に一つのCPUしか使用しないため、CPU 0～CPU 3のいずれに割り当てても、いくつ割り当てようとも結果は同じとなる。そして複数実行した場合は、各々の実行スレッドは独立して実行されることから、スレッド同期を行う必要がないため、実行スレッドの間口が増えるHyper-Threadingの有用性を確認できた。
一方、TMPGEncのようなマルチスレッドアプリケーションでは、基本的にプロセスが支配下に置くことのできるスレッドを一つ一つCPUに割り当てることができるので、スレッドの数だけCPUがあれば、それだけ有効に利用することができる。だが、TMPGEncでは実行スレッドが二つのみであること、スレッド間同期またはプロセッサリソースの占有率の高さ等によって、実質、スレッド毎に物理プロセッサを割り当てなければ意味がないことから、 TMPGEncの複数同時実行だけでなく、単体実行においてもHyper-Threadingの有用性を見出すことはできなかった。
以上の結果を踏まえて、Super πとTMPGEncを同時実行させたとしたら、どういう予想を立てることができるだろうか。単純に考えれば、２つの実行スレッドのプロセッサリソース占有度が高いと目されるTMPGEncが物理プロセッサを乗っ取ったなら、Super πはプロセッサリソースが有効に使うことができず、停止状態に陥ってしまうということが予想できるだろう。これでは、Hyper-Threadingを活かすことはできないとなるのは明白である。
以上のような予想を立てつつ、最初に行う同時実行テストはデフォルトの状態、つまり、CPUの割り当てを特に設定することなく（CPU割り当て上は、CPU 0～CPU 3すべてを当てている）、行った結果から示してみよう。
と、その前に。TMPGEncのテストは従来のものと同様だが、Super πのテストは、通常行う104万桁の計算でなく、52万桁の計算に変えている。変えた理由だが、TMPGEncのテストと実行タイムをなるべく合わせるため、TMPGEncが通常42秒で処理を終了することから、これに近い38秒で処理を終了する52万桁を採用したということである。
では、デフォルトでの同時実行の結果だ。
デフォルト状態（すべてのCPUが割り当て）で、Super πとTMPGEncを同時実行。
いきなり面白い結果となった。Super πについては、初めて52万桁の計算を行ったため、実行タイムが目新しいタイムとなるのはもちろんだが、TMPGEncの実行タイムは54秒という、これまでにまったく見たことのない実行タイムとなった。これまでは、マルチスレッド（２つの実行スレッド）が有効に機能した42秒前後の実行タイムと、実質シングルスレッドのみが有効となった1分25秒前後の実行タイムしかなかった（TMPGEncを複数実行した際に、一方のTMPGEncによってすべてのプロセッサリソースを奪われた場合は実行タイムが大幅に遅れたが、これは例外）。それがこのテストでは54秒とどちらともつかない中途半端なものなのだから、これはじっくりと検証する価値があるというものだろう。
手始めに、物理プロセッサをSuper πとTMPGEncそれぞれに割り当てたらどうなるかを確かめてみよう。シングルスレッドアプリケーションであるSuper πは、プロセッサリソースをTMPGEncに奪われることなく実行できるので、おそらくは単体テストと同様の38秒程度か、あるいはそれよりやや時間がかかる程度であろう。一方、TMPGEncは、物理プロセッサ一つでは実質マルチスレッドを有効に活用できないので、マルチスレッドオプションを無効にした 1分25秒程度と予想できる。
それでは、CPU 0とCPU 2をSuper π、CPU 1とCPU 3をTMPGEncにそれぞれ割り当てた結果をご覧いただこう。
CPU 0とCPU 2にSuper πを、CPU 1とCPU 3にTMPGEncを固定して実行。
何かすいぶんとベタな予想とその結果だと思われるかもしれないが、これが現実である。何度計測しても同じような結果なので、引き続き、Super πをCPU 0だけ、そしてTMPGEncをCPU 1だけに割り当て、残るCPU 1とCPU 2にはこの二つのアプリケーションを割り当てないような形でテストを行ってみた。結果は以下のとおりとなった。
CPU 0にSuper πを、CPU 1にTMPGEncを固定して実行。
シングルスレッドアプリケーションであるSuper πが、CPUの割り当て数を減らしても結果が変わらないのは自明だが、マルチスレッドアプリケーションであるTMPGEncがマルチスレッドオプションを有効にしておきながら、それが機能していないように見えるのは、これまでに指摘しているように物理プロセッサを一つだけしか割り当てていないことによるものだろう。改めて、Hyper-ThreadingがTMPGEncでは有用でないことが確認できたといえるものだが、今はそれに注目しているのではない。TMPGEncの実行タイムが54秒となる組み合わせとしては、物理プロセッサをそれぞれに割り当てたものではないという結果が重要なのである。そうなると、次なる組み合わせは、物理プロセッサをまたがった割り当てでテストを行うことが適当だろう。CPU 0とCPU 3をSuper π、CPU 1とCPU 2をTMPGEncと割り当てた結果は次のとおり。
CPU 0とCPU 3にSuper πを、CPU 1とCPU 2にTMPGEncを固定して実行。
Super πが１秒ほど速くなっているが、誤差の範囲だろう。これが、デフォルトの状態で行った結果と同等であるのはほぼ間違いない。それでは、このテストを実行中のCPU使用率は、どう推移したのだろうか。これも実に興味深い結果を示している。
Super π（CPU 0, CPU 3）とTMPGEnc（CPU 1, CPU 2）同時実行時のパフォーマンスモニタ
CPU使用率は、同時実行中は75%（Super πにCPU２つを割り当てているが、実行スレッドは１つのため）を示していたが、Super πの処理が終了した後のイメージショットなので画面上は50%となっているが、注目はCPU 0（CPU使用率の履歴の最左）とCPU 3（同、最右）のぶれの大きさである。これまでCPU使用率の履歴をいくつか示してきたが、Super π及びTMPGEncを実行中は、常に振り切れた状態、つまり上で見ると真ん中二つのようになっていた。この激しいぶれは一体、何を示しているのだろうか。
───というところで出勤時間が来てしまった。この続きは、また次回以降ということですいません。（2002/1/23）
【当時を思い起こして】
───というところで出勤時間が来てしまった。この台詞で終わることはかなり多かったように思う。だいたい、巻頭言に費やしていた時間は概ね30分。専ら出勤前の朝に書いていたのであった。今は昔。人生を充実させるために、現在はそういう時間を朝取ることはかなわなくなったが、それはそれでよかったと思っている。
コメント