LAPACK-3.2.2 & BLAS-1.0
- Netlib.orgで配布されている参照実装
- ライセンス的には一番緩い？(原著者への正しいクレジットの表記のみ)
- 最適化BLAS & LAPACKがおかしいときの比較用に持っておいて損はない
- 3.2.2でも実用上問題になる Errtaが有るので、Errataリストには目を通すこと
ATLAS
- 3条項 BSDライセンス(宣伝条項無し)
- 比較的に広い環境でそれなりの性能が出るソース付き最適化BLAS & LAPACK実装
- コンパイル時に行う自動チューニングの時間が長いのが玉に瑕
- 安定版の3.8.3と開発版の3.9.x系列がある
  - 一部環境では、3.8.3の性能に難があるため 3.9.xがおすすめ(Opteronでの QR分解とか)
GotoBLAS-2.1.3
- ソース付きだがライセンスは厳しい(再配布は出来ません)
- Texas Advanced Computing Center製後藤BLASの最終版らしい(中の人がMicrosoftに移籍)
- 埋め込まれるLAPACKは、少し古めのLAPACK-3.1.1なので Errataに要注意
  - LAPACK-3.2.xでは修正済みの結構致命的なErrataがある
  - Working areaの LQUERY系は運用でごまかせるが、収束性や停止性にまつわる致命的 Errataあり
- ソース付きの最適化BLAS & LAPACKとしては私の知る範囲では最速、測定条件によっては商業ライブラリを上回る性能を叩き出す
ACML-4.0.0
- AMDが自社CPU向けに用意してる最適化BLAS & LAPACKを含む数学ライブラリ
- 開発者は、無料でダウンロード可能
- Windows/Linux向けのバイナリ提供のみ
- Linux gfortran環境向けバイナリなら、ELFかつLinuxと ABI互換な gfortran環境で利用可能と思われる
IMKL-10.3
- Intelが自社CPU向けに用意してる最適化BLAS & LAPACKを含む数学ライブラリ
- 商品なので購入してください(単品もしくはC/Fortranコンパイラ商品に付属)
- Windows/Linux/MacOSX向けのバイナリ提供のみ
  - 基本的には Intelコンパイラと組み合わせ
  - gfortranも可能だが、4.4.0以降はサポートしない(libgfortran APIが変更されてる)
NAG Fortran Library
- Numerical Algorithms Groupの最適化BLAS & LAPACKを含む数学ライブラリ
- 商品なので購入してください
- Windows/Linux/MacOSX向けのバイナリ提供のみ
- BLAS & LAPACKにも nagの中の人のクレジットが入るくらいなので品質と性能は信用できる
NVIDIA CUDA BLAS
- CUDA Toolkitに含まれる Tesla/Fermi GPU上で動く並列BLAS
- 行列サイズがある程度大きければ、CPUは追いつけない(演算・メモリ帯域的に)
- 今時のMany coreマシンで、複数ユーザーが同時にジョブを流す場合は問題有

ほかにも、Fortranコンパイラベンダ謹製の最適化BLAS & LAPACKがあるようです

手元の Opteron 2376で測定した固有値分解(*GEEVX)やSVD(*GESDD)の single core性能だと

GotoBLAS-2.1.3 > ACML-4.0.0 > ATLAS-3.9.11 >> ATLAS-3.8.3 >> LAPACK-3.2.2

でした。

ATLASに関しては、3.9.3辺り QR分解まわりの改良が効いてるのか安定版と大きな性能差が出ました。

トップ３ライブラリの差は10%前後ですが、GotoBLASの速さが目立ちました。 (ACML-4.0.0と ATLAS-3.9.11は、結構接戦でした)

まとめると...

LAPACK-3.1.1の Errataを考えると ACML-4.0.0か ATLAS-3.9.xを選ぶのが better
Errataを避けられる用途に限定する場合、GotoBLAS最速

[ツッコミを入れる]

2025-11-11

_ [SAD]filevmアロケータアイデア

思いつきメモ

MAP_GUARD拡張を使ったvmアロケータはmmap(2)の拡張に依存するので移植性がないので、POSIX/SUSで移植性のあるアロケータのアイデアをメモメモ

初期化手順

mkstemp(3)でbacking store fileをopen
file system namespaceからunlink(2)する
ftruncate(2)で、16GiBへ拡張する
mmap(2)でbacking store fileを仮想メモリに割り当てる
mprotect(2)で、一旦書き込み禁止にする or mmap(2)時点で PORT_NONEで割り当てる

割り当て

backing store fileから新規割り当て領域分をmprotect(2)でPORT_READ|PORT_WRITEに変更する
- 実際のページ割り当ては、Copy on Write時に行われる

リソース使用量の考察

ftruncate時点では、hole fileなのでfile system blockは未割り当て
書き込み時のCopy on Write動作で、VM block割り当てが実施される
- 未初期化ページのbacking storeはhole file backedなので、VMが最適化されていればzero fillされた単一のdummy pageで賄える
- MAP_PRIVATEで割り当てるとCoWされたpage差分は、anonymous pageとしてVMから割り当てられる
  - over-commit有り環境だと、MAP_GUARD拡張による実装に近い動作になる
  - over-commit無し環境だと、VM backing storeが不足するとmmap(2)の時点で弾かれる点で、MAP_GUARD拡張実装と異なる
- MAP_SHAREDで割り当てるとCoWされたpage差分は、file backed pageとしてVMから割り当てられ、適宜write backされ page drop対象になる
- madvise(2)等でWrite Back動作を制御しないと、不要なWriteBackが負担になる
終了時は、file descriptor開放に伴い link count zeroとなりfile systemから開放される
- Write backを発生させる場合、I/O性能的にlocal file system上が望ましい

実装上の考察

32bit環境のケースのfallbackは実装すべき
MAP_GUARD拡張によるbackendと類似の構造になるので、コードの共通化を考えるべきか？
最初の初期割り当てサイズを制限するノブを付けておいたほうがよい (メモリリーク時に早期にアボートさせる用)
MAP_SHAREDなbacking storeを採用する場合、backing storeのパスを設定可能にすべき

[ツッコミを入れる]

カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記