Automated Empirical Optimizations of Software and the ATLAS project

http://citeseer.ist.psu.edu/whaley00automated.html

以前、FFTWをちょろっと眺めたので、ATLASについても眺めて見た。論文は、どうでもいい話が長いので、
http://www.ueda.info.waseda.ac.jp/~ishizaki/pukiwiki/pukiwiki.php?%BF%F4%C3%CD%B7%D7%BB%BB%A5%E9%A5%A4%A5%D6%A5%E9%A5%EAATLAS#content_1_1

コンセプト的には、ATLASは、FFTWの線形代数版みたいな感じで、色んなアーキテクチャに対して、ライブラリを人間が手でチューニングすんのは面倒、自動的にチューニングしようぜ、というような話。けどまあ、FFTWとは、大分やり方が違う

FFTWの方針は、
・原則として、コードレベルでは、"portable"で、マシンレベルの最適化は、plannerが実行時に最適なcodelet(固定したサイズのDFTを計算するコードみたいなもん)の組み合わせを見つけることで行われる
・codelet部分は、genfftが自動生成。codeletは、とにかく、単純に足し算と掛け算の数を減らす
みたいな感じだと思う。

FFTWで、codeletの演算回数を絞るのが、どの程度高速化に寄与してるのかは知らんけど、ATLASの方は、演算量減らすとかはどうでもよくて、メモリアクセスが重要という考えで、うまくレジスタやらキャッシュを使おうというような(FFTWが、そういうのを無視してるというのは言いすぎだけど、でもまぁ直接的には何もしてないし)。そういう最適化は、多分すごい昔から知られてるので、ATLASがやったことってのは、(インストール時に)色んなコードを自動生成して、自動でベンチマークかけて、一番効率のよいのを選ぶ、という人間が手動でやってたことを、ほとんどそのまま自動化した感じっぽくて、あんまり面白みはないような。

あとまあ、ソフトウェアをハードウェアに合わせてチューニングするんじゃなくて、ハード作ろう的な流れはあると思うんだけど。BLAS API(まあ、大体は、行列の掛け算なDGEMM)をFPGAで実装したとかいう論文は、結構あるけど、今のとこ、そういうのが特に利用されてるようでもないし、実際んとこ、汎用CPU+ATLASの組合せと比較して、そんな速いわけでもないか、むしろ遅いというのが実態らしい。遅い理由は、実装が悪いとか、データ転送がボトルネックになってとか色々あるだろうけど。FFTの方は、DSPとかはあるけど、HPCでFFT on FPGAが利用されてるとかって話もあんま聞かないし、どうなんだろう。