■ SPHのGPU実装テスト 
ConputeShaderの練習もかねてSPHを試してみてるんだけど、CPUで数倍高速化したアルゴリズムをそのままGPUに持っていったら、数十倍遅くなってしまった。何度も使用する２点間の距離の計算をメモリにキャッシングしてたんだけど、それをやめただけで倍くらい早くなった
計算回数よりもメモリアクセスの最小化のほうがずっと重要で、下手にメモリを見に行くよりも毎回再計算した方がずっと早くなるっぽい。今回のCPU側の最適化を一旦メモリに書き出すことで後段のループ回数や計算量を減らす方向で進めたのが間違いだったみたい
距離や近隣パーティクルのインデクスなど、パーティクル構造体にいろんな情報を埋め込んで肥大化したのが原因の一つになってるみたい。キャッシュヒット率が変わるせいか、GPU側はパーティクル構造体のサイズを変えるだけでもかなり速度が変わってくる
いろいろ試してたら一応CPUのシングルスレッドよりは早くなったけど、マルチスレッドで動かしたらまだGPUの方が遅い。データ構造からの根本的な対処が必要そうだけど、シェーダーのコンパイル時にループ展開などでかなり最適化されてるみたいで、どうしたら早くなりそうかの挙動が読みづらい
CPU側はOpenMPを有効にしてループの前にparallel forと書くだけで、4コア8スレッドの環境で4〜5倍くらい早くなってくれたりするので、面倒な手続きが必要なGPUに比べるとすごく楽だった
アルゴリズム修正前は単純にGPUに持っていくだけで10倍くらい早くなってたので、今回もそうなることを期待してたんだけど甘かった。もうちょっとGPUの気持ちになって考えられるようにならないといけなそう
@Samieru_NIGORO 最近のCPUはキャッシュが馬鹿でかいので、CPU側はすべてキャッシュに乗ってて問題ないのかも、でしょうか。３次キャッシュには十分収まるサイズなので。GPUだとベクトルの引き算＋sqrt程度なら、メモリにアクセスするよりも圧倒的に高速な雰囲気です
@Samieru_NIGORO できればCPUとGPUでせめてアルゴリズムだけでも共有したいところだったのですが、データ構造まで変えるくらいの個別の最適化が必要になってくるとちょっと面倒ですね。本来はソース共有して一つ書き換えれば両方で動くのが理想的ですが、いろいろ難しそうです
