幾霜::残日録::2011/12/15 (木)

　というわけでやってみました。OMP_NUM_THREADS=8にするとCPUが750%くらい使われているので並列化はうまくいっているようです。計算結果の方も1並列の場合と全く同じなので、良さげな感じですね。800%にならないのはメモリかディスクかプログラムのどれかがボトルネックになっているんだと思います。たぶん共有変数を同時に書き換えしないように#pragma omp criticalしているので、その辺じゃないかと思います。もしくは逐次処理部分。並列度を9以上にしたらどうなるんやろか。

追記 - 04:29:12
　速度計測してみた。アセンブル対象はAMOSのtutorialにあるmetagenomeデータ。OSはGentoo Linux x86_64、CPUはCore i7 860 (Lynnfield)。下記の所要時間はあくまでhash-overlapにかかった時間。スケジューリングはguided,5です。

1 thread 5m49.227s
2 threads 3m2.064s
4 threads 1m35.536s
8 threads 1m21.292s
12 threads 3m2.723s

　かなり速くなっていますね。CPU使用率は8並列で750%くらいになっています。計算中、何故かゆっくりとしか上昇しないのが謎です。上記の結果を見る限り、並列度を論理コア数より大きくしても意味はないようですね。おそらく同期を取るところの待ち時間が増えてしまうのでしょう。CPU使用率を比較すると、8並列までは線形に近い上昇ですが、それ以降は並列度を上げるにつれてどんどん下がっています。論理CPUの使用率が上がっても、分岐予測の外れがあまりないせいか、HyperThreadingの効果はあるにはあるのですがわずかですね。悩みどころはやたらとsegmentation faultになること。しかし同じ処理を何度か走らせるとうまくいくこともある・・・。謎だ。ただ、timeで時間を測っているときにしか起きていないような気はします。

　ともかく、ちゃんと動作するのであれば、これでアッサムズのマージ処理がかなり高速化しそうです。

追記 - 06:26:37
　不規則にsegfaultになる問題が解決できない。なんでこうなるんや。

追記 - 06:42:33
　「OpenMP "segmentation fault"」で検索したら一発やった。どうやらマルチスレッドプログラムではよくあることらしい。スタックサイズの上限とやらを大きくしてやればいいとのこと。環境変数OMP_STACKSIZEで指定するもよう。試しに盛大に2Gと指定してやったがダメ。どうもbash上の設定を変えないとダメみたいで、

ulimit -s 819200

としました。が、それでもダメ。他の問題か? 不規則に落ちるというのが解せない。規則的なら対処のしようもあるんですが。

追記 - 16:16:44
　複数スレッドから同時にメモリの同じところを書き換えしようとしているから、衝突することもあれば衝突しないこともあるのではないかと思われたので、coreファイルを生成させてgdbに食わせることで場所を特定しました。あー、そこでメモリの書き換えしとったんか、という感じ。まだ同様の箇所があるかもしれませんが、とりあえず一歩前進。

追記 - 18:09:06
　core吐かせてgdbに食わせたら、並列化していない部分でsegmentation faultしている。理解不能。もちろん並列化切れば起きないんですが。こういうときどないすんねん。

追記 - 19:52:41
　並列処理でAを作る→逐次処理でAを参照してBを作る→並列処理でBを参照、という感じの処理をしていました。最初の並列処理でAがちゃんとできていないために逐次処理でAを参照する段階で落ちていたわけで、最初の並列処理をやめたらうまく行きました・・・。下の階のM大先生のおかげで助かりました。感謝感謝。