高精度計算 on many core CPUは難あり

色々試したあげく、思ったことは、
高精度計算 on many core CPUはOpenMP程度の高速化では難があるということだ。

最初思うことは、GPUでの高速化だが、高精度計算は(double-doubleのようなアプローチをのぞき)、分岐が多いため
GPUでの高速化には向かない。従って昨今マルチコア化けが進んできたCPUで行うというふうに思うのが常識的な
判断であろう。またメモリのアクセススピードが相対的に低下、または、今後このままの技術延長上には高速化の
余地はあまりない、ということでbytes/flopが下がってきたわけで、高精度計算は相対的に高速化されるはず
と見込んでやっているのであるが(正確にはモチベーションのごく小さい部分なのだが他の人にはわかってもらいやすい
モチベーションである)。

また、AMDの石では行列のサイズが大きくなるとCPUまたはスレッドの数を増やしてもパフォーマンスが
増えない、むしろ悪くなることもある、ということである。

さらに、__float128はgccのIEEE 754 2008のbinary128をソフトウェアで実装したものについては
double-doubleとはほぼ同精度であるにも関わらず10倍程度遅かった。

GMPのパフォーマンスは石を選ぶようで、必ずしも新しいのが良いという訳ではなかった。

IntelのコンパイラはAMDの石でも常に良い性能を示した。

Intelの石は比較的素直な性能を示したが、パフォーマンスには不連続なところが見られた。急に
パフォーマンスが良くなる行列のサイズがあった。

SIMDはスレッド数をあげれば自動的に使ってくれるかと思ったがそうではないということがわかった。

AMDはアーキテクチャ上NUMAを意識しないとパフォーマンスが出ないことがわかった。OpenMP程度でも
これを強く意識しないとダメということだ。

Rgemm gmp (gcc 4.6.3 compiled) on AMD Opteron Magny-Cours 2.4GHz 48 cores

藤澤先生から
Opteron Magny-Cours 2.4GHz 12x4コアのマシンをアクセスさせてもらった。そこで、Rgemm gmp のベンチマークをとってみた。
IntelのコンパイラでのバイナリはAMDの石では遅くなる可能性があるからだ。

* マシン:AMD Opteron Magny-Cours 2.4GHz 12x4 = 48 cores
* MPACK 0.7.0 (SVN)
* gcc 4.6.3
* reference implementation + openmp
* Rgemm (dgemm like routine), すべて正方行列、初期値はランダムな行列。
* スレッド数は1,2,4,8,16,...など変えた



結果はIntel composerの勝利で、gccではかなり性能も不安定に見える。

Rgemm __float128 on AMD Opteron Magny-Cours 2.4GHz 48 cores

藤澤先生から
Opteron Magny-Cours 2.4GHz 12x4コアのマシンをアクセスさせてもらった。そこで、Rgemm __float128 のベンチマークをとってみた。
これはIEEE 754 2008で定義されているbinary128のgccでの実装である。

* マシン:AMD Opteron Magny-Cours 2.4GHz 12x4 = 48 cores
* MPACK 0.7.0 (SVN)
* gcc 4.6.3
* reference implementation + openmp
* Rgemm (dgemm like routine), すべて正方行列、初期値はランダムな行列。
* スレッド数は1,2,4,8,16,...など変えた



300MFlopsとddと比較するとほぼ同じ精度なのに10倍も遅い!!
行列のサイズが大きくなると、おそくなるというのは今回は見られなかった。
きっとメモリアクセスはボトルネックにならない程度に演算が遅いのであろうと思われる。

gcc compiled Rgemm DD on AMD Opteron Magny-Cours 2.4GHz 48 cores

藤澤先生から
Opteron Magny-Cours 2.4GHz 12x4コアのマシンをアクセスさせてもらった。そこで、Rgemm dd のベンチマークをとってみた。
今回は、gccを用いた。Intel ComposerはAMDの石ではパフォーマンスが出ない可能性があるため、それを比較するためである。

* マシン:AMD Opteron Magny-Cours 2.4GHz 12x4 = 48 cores
* MPACK 0.7.0 (SVN)
* gcc 4.6.3
* reference implementation + openmp
* Rgemm (dgemm like routine), すべて正方行列、初期値はランダムな行列。
* スレッド数は1,2,4,8,16,...など変えた

ピークパフォーマンスが、3.5GFlopsから3GFlopsまで落ちている。行列のサイズが大きくなるとほぼ同様のパフォーマンス下落がみられた。

首都大講義分析化学II四回目

四回め。

さて、教科書が不具合散見されるので、どうしたらいいのか思いあぐねる。つまり、
定義をせずになんとなく文脈から言葉を定義するような書き方をしているところがあるのだ。
具体的には、酸化還元滴定の章には、酸化還元滴定の定義が書いてなかった。文脈からは、還元剤か酸化剤を
用いて滴定するということがなんとかわかるが、さすがに不親切であろう。著者に連絡を取って議論したい気にも一瞬なるが...

で、やっぱり学部生相手の授業というのはどうしても研究の話ができず、単調になってしまった。
教科書の書き方は高校生レベルであった。ロジカルには全く問題がないが、大学で習う微積で
エレガントに処理したいものである。高校までの数学、物理だとどうしても微分積分がいい加減なので
不満もたまるが、ちゃんと実数から始まる微積をやると、いろんなものがキッチリ処理できてすっきり
する。微積はそもそも物理(ニュートンやライプニッツ)からきているものなので相性は抜群である。

前回は比較的優秀だったので今回は、センスを問う問題を出してみた。今回のセンスとは、物理的、化学的な
近似とは何かということである。どの物理量がどの物理量より小さく無視できる、ということである。
授業中連呼してみた。数名、ちゃんとわかってくれている人がいた。

今回も午後二時半くらいからの、眠い時間まじめに皆さん聞いてくれてうれしかった。
ありがたいです。