2011年2月12日土曜日

GotoBLAS のマルチスレッドで SDPA が遅くなる理由

一日かけて、GotoBLAS のマルチスレッドで SDPA が遅くなる理由を探ってみた。

まず、シングルスレッドに比較してどの問題について遅くなるかを特定したところ、
量子化学の問題やtheta6.dat-s はマルチスレッドのほうが高速で、
control11.dat-s だけマルチスレッドにすると極端に遅くなる。

control11.dat-s は Schur complement 作成のときに F1 の式にかかる負担が大きいのが特徴で、マルチスレッドの場合もここが遅くなることがわかった。さらに F1 の式を詳しく見てみると、
X*Ai (Xは密行列、Ai は疎行列）の計算が99% 近い計算時間を占めている。
この中は daxpy を呼び出しているか、dgemm を呼び出しているのであるが、control11.dat-s の場合は、dgemm を F1 では呼び出していない。

結局のところ、問題が起きているのは daxpy のようである。
１回１回は 1 milli second 程度であるが、これが200万回程度呼ばれており、全体として 1300 秒程度（SDPA合計の95%以上）を占めていた。

今使っている GotoBLAS は DYNAMIC_ARCH なので、おそらく daxpy に入るたびにスレッド数などをチェックしているものと推測され、これが計算時間の負荷になっているのだと考えられる。
今はWARMUP を切っているので、WARMUP をつければ改善するのかもしれない。
これは、またチェックしよう。

今日の作業内容：GotoBLAS チェック 6h
明日の予測作業時間: 3h
投稿者 時刻:

2 件のコメント:

  1. Fujisawa2011年2月15日 2:03

    この SDPA のソースってどのバージョンでしょうか？
    最新版では、このスレッドの衝突の問題は回避してありますので（根本的に解決するのは難しいですが）、SDPA(マルチスレッド)+GotoBLAS2(マルチスレッド)で controll11.dat-s は 25秒程度で解けます(Intel Xeon X5670 x 2 = 12コア)。

    返信削除
  2. Margaret2011年2月15日 8:20

    いま使っているのは、Debian にアップロードしてあるのと同じSDPA 7.3.4 です。
    SDPA のコマンドラインからは -numThreads を指定していないので、F1 を実行しているのは現状では１スレッドだけです。
    なので、とりあえず、daxpy の中かなぁ、と思ってもいます。

    そちらの最新版も試して比較して、ほんとに daxpy で遅くなっているのかどうか確認してみたいところでもあります。

    返信削除

登録: コメントの投稿 (Atom)