x86の命令スケジューリング

x86では命令スケジューリングしない、という方法が結構有効である。

  • レジスタあんまり無いのでそもそもできない
  • 整数演算がレイテンシ1とかなのでスケジューリング必要ない
  • OoOなのでスケジューリング必要ない
  • Core2では恐怖のROB read port stallsがあるのでむしろスケジューリングすると遅くなる

なのだが、Atomで浮動小数演算すると、この前提はすべて崩れる。

なので、Atomで浮動小数演算するときはスケジューリングしたい。ただ、「Atomで浮動小数演算性能が欲しい」ってどんな前提条件だよ、という感じであるので、まあ、ほぼ実用上は「x86では命令スケジューリングしない」で、大丈夫だといえる。(あとx86でスケジューリングが必要なほど性能求められたら、アセンブリ書いてトライアンドエラー以外の方法が思いつかないというのもある。誰かあれどうしたらいいか教えてくれ)


個人的には、ハードウェアでなくて、ソフトウェアで問題解決するのは好きなので、インオーダーのAtomで浮動小数の命令のスケジューリングというのはやってみたい。とは、思う。が、あまりニーズはないね。まあ、そのうち。

スケジューリング

http://www.gdep.jp/column/view/3 の
https://www.gdep.jp/files/image/column03_blocks_threads.jpg
の表なんだが、なんか似たような表を見たことがあるな…
僕がCUDAのコード書くときは面倒だからスレッド数128 or 256でブロック数=SM数決め打ちでやるのだが、ブロック数=SM数決め打ちはあんまりよくないみたい。


…と、いうのが、表を書くことでしかわからないというのが許せないのだった。


CUDAは、「命令のレイテンシ隠蔽」「メモリのレイテンシ隠蔽」「SIMD」「SMP」というあたりを全部まとめてマルチスレッドで扱えるのがシンプルで素晴らしいわけだが(実際にはブロック内のスレッドが微妙だけど)、これらの概念をひとつにまとめてしまったため、「マルチスレッド」という概念がいろんな要素を含んでしまって、「全部実測して表を書かないとわからない」という状況になってしまう。

CellのSPUのようにこれらを全部手で書くのと、CUDAのように全部まとめて扱ってしまうのと、どちらが簡単なのか、というと、個人的には、CellのSPUのほうが簡単な気がするのだが、いやでもそうか？実際最適化すると最後はトライアンドエラーになるわけで、そうなったら表を書くぐらい全然問題無いんでは？という気もしてきたな。えーと、特に結論とか有用な情報とかはない。

いや

最初からあの表(仮にTB(Thread Block)表としておく)を書く前提でプログラム書いていれば、TB表を書くだけで自動的に最適値が求まる、と、考えれば、x86のようにプリフェッチの距離どのくらいにしたらいいかわからなくて手当たり次第に試す、とかよりも美しいという気がするな。


つまり、あらゆるものをマルチスレッドで扱うようにしたから、チューニングパラメータもスレッド数の調整だけになって美しい、と考えるべきか。
(まあ、実際のチューニングにはもっと細かい問題があるので、それだけで問題が解決するわけではないが、細かい問題は大体どのアーキテクチャでも平等に存在するので、とりあえずここではどうでもいいとしておく。)

コーディング時無呼吸症候群

全然関係ないが、定期的に息ができなくなる夢を見ることがあって、最近まで、あまり気にしてなかったんだが、これいわゆる睡眠時無呼吸症候群というやつでは？という気がしてきて、それ以来、「自分がいつ息をしてないか」を意識して観測するようにしていた。

で、気付いたのだが、なんか、コード書いてるときは半分くらい息をしてないことが発覚した。大丈夫か？死ぬんじゃないの？
あとボルダリングしてるときも、「息してない」とか指摘を受けたな。なんか集中したら息をしてないっぽい。

もっとちゃんと息をしたほうがいい。