LAPACKルーチン、、、およびを使用して、パックされた対称行列の反転と乗算を実行するコードがDPPTRFありDPPTRIますDSPMV。これは、 LAPACKルーチンを呼び出すために使用するC++コードを見ることができる古いトピックです。
私のコードは現在、ほとんどが対角線に沿って配置されている対称行列を組み立てています。
さまざまなBLASおよびLAPACK実装をテストしており、GotoBLAS2をnetlibの参照LAPACK実装と比較しています。
これが私がnetlibLAPACKコードをコンパイルする方法です。.fソースからコードファイルを選択し、それらをすべて次のようなコンパクトな静的ライブラリにコンパイルします。
$ ls
ddot.f dpptrf.f dscal.f dspr.f dtpsv.f lsame.f
dgemm.f dpptri.f dspmv.f dtpmv.f dtptri.f xerbla.f
$ gfortran -c *.f
$ ar rcs liblapack_lite.a *.o
次に、を使用してこのライブラリをC++アプリケーションにリンクできます-llapack_lite -lgfortran。
次に、GotoBLAS2を使用してみました。ここからもらった。パッケージには、19MBの大規模な静的ライブラリを自動的にコンパイルするスクリプトが含まれていました。リンクすることで、既存のコードとうまく連携します-lgoto2_nehalemp-r1.13。
最初はうまくいったと感じました。GotoBLAS2を使用すると、大きな問題セット（1000x1000以上の行列を反転する）で、パフォーマンスが約6倍向上することがわかりました。GotoBLASは私のアーキテクチャ用にスレッド化されており、リファレンスLAPACKはシングルスレッド化されているので、これは妥当だと思いました。システムモニターは、確証するために300％を超えるCPU使用率も示しました。
ここがおかしくなるところです。リファレンス実装を最適化するとどうなると思いますか？
lapack_litelibを次のように再コンパイルします。gfortran -c -O3 *.f
私のlapack_litelibは、 1つのスレッドのみを使用して、3200x3200のマトリックス反転でもGotoBLAS2よりも優れています。また、RAMの消費量が最大80MB少なくなります。
ただし、後続のパックされた行列-ベクトルの乗算は、GotoBLASを使用するとより高速に行われます。
これはリモートでも可能ですか？GotoBLASパッケージのmake構成は、gfortranで最適化スイッチを使用できませんでしたか？