7/27 LlanoはZacateよりマシな模様

APU + OpenCLのレイテンシなどを計測している方のページ。
Llanoではだいぶ改善されている模様。

http://d.hatena.ne.jp/w_o/201107

7/15 map/unmap

メモリアクセスのAPIを変えて実験しているのだが、ヒープメモリ関係のバグが発生している。
原因はよくわかっていないが、最後にメモリをfreeしている場所でエラーが起きる。
大事な部分は全部mallocで確保しているので、ヒープは関係ない気がするのだが何なんだろう。

そもそもmap/unmapのAPIが正しく使えているのかが怪しいが、
検索してもそれらしい記述にたどりつくことができない。


先日まで取り組んでいたWindowサイズを変える実験も、
Windowサイズが大きくなると実行時間が減ってしまう部分があり、
実験結果の信憑性が疑われるのだが色々探しても原因やバグは突き止められなかった。
こちらもよくわからないが、とりあえず進捗が芳しくなく中間発表が恐ろしい。

7/11 実験の謎

ウィンドウサイズを4から1024まで2倍刻みで実験したのだが、
CPU/APUともほとんど実行速度に影響がなかった。
ウィンドウサイズを増やすと浮動小数計算量もメモリ転送量も2倍ずつ増えるので、
現在のデータ量では少なすぎるのだろうか。

ウィンドウサイズ1024、Ticker数640では、単純にウィンドウが占めるメモリ領域だけで、
配列長1024 x 2本 x 4Byte(float) x 640種類 = 5MBになる。到底L2キャッシュに収まる容量ではない。
シーケンシャルアクセスしか行われないので、CPU側への影響は薄いのかもしれない。
APU側のデータ転送時間にも全く影響のないところをみると、
ほとんどが呼出コストで、送受信自体はゴミのような時間しか食わないのか。
もしくはゼロコピーなるものがこっそり仕事しているのかも。

計算量もウィンドウサイズ4でTicker数1ならば掛け算と足し算が配列長分ずつ必要なので、
8回の浮動小数計算だが、ウィンドウサイズ1024でTicker数640ならば2 * 1024 * 640 = 1310720回になる。

CPUが1.6GHzなので、1サイクルは0.625ns。
浮動小数命令が今何サイクルかかるかよく知らないが、1サイクル以下はありえないので、
1で考えると1310720 x 0.625ns = 0.8192s。意外と短い。
計算量が少なすぎて、大した違いにならないのかもしれない。

もっと大規模データで実験しないといけないのだろうか。
実験の方向性がよくわからなくなってきた。