2009年03月31日

そろそろCell/BEについて一言言っておくか

プログラムを書いてみて思ったのは、とてもじゃないがSPEを使ったプログラミングはペイしない、ということです。高速化に掛かる開発コストが計算コストと比較して高すぎます。計算インテンシブなタスク(今回のタスクは計算量がO(n^2)で通信量がO(n)です)でこうなのですから、通信が大きくなるに従いさらに厳しくなるでしょう。シミュレーション用途ではCellに載っける開発コストが高すぎ、シミュレーション時間と比較してペイするのは相当長時間のタスクです。リアルタイム性能が要求されるゲームでも、よほど重い処理でなければペイしないでしょう。それなら計算する内容を減らせ(減らせないほどこだわりがあるゲームを作るなら別ですが……)と言うことになります。結局、これでは誰のためのCPUなのか分かりません。
いろいろ考えたのですが、大きな問題は次のあたりだと思います。

  • メモリ転送を自分で書く、というモデルはプログラマに仕事を押しつけすぎている。共有メモリと一貫性を取らないキャッシュのように、プログラムから見えないように実装した方が(たとえパフォーマンスが落ちても)ずっと良かっただろう。DMAを書くのは__builtin_prefetch()を書くよりずっと大変。MPIはOpenMPより大変なんです!
  • 言語でのサポートがきわめて貧弱。並列プログラミングはリソースの割り付けが最重要課題なのに、そこへのサポートが無いに等しい。
  • 用意されている通信ライブラリも貧弱。殆ど通信プリミティブしかない。
  • パフォーマンス計測手段が足りない。速いCPUよりボトルネックが見つけやすいCPUが重要。


というかまぁ正直なところ<過激>高速化するのにコンサルタント会社が必要なCPUは滅びて欲しい。</過激>新しい命令セットを持つCPUは、ただでさえ移行コストが高いのですから、ここら辺はCPU以上にお金を掛けて欲しかったと思います。正直なところ、現在のサポート状況を見ていると、供給会社の皆さんが本気でCellを普及させるつもりがあるのか疑問です。つかI○MはPOWERが売れれば良いんじゃないかな……。そうそうSPARCどうなるんだろうね……。新SPARCのレジスタの扱い方気に入ってるんだけどね……。

逆に良いところは、

  • 128 bit幅のレジスタが128個もある。
  • ローカルストレージの存在自体は回路規模と比較すると良い交換だと思う。これがキャッシュならもっと良かったのに……。
  • 通信の粒度に応じたSignal / Mailboxなどの存在。
  • 一見何に使えるのか分からないshuffle命令。萌える。
  • ループ内部はパフォーマンスが予測しやすい。打てば響く高速化は重要。
  • パイプライン可視化ツール。でも命令数増えると動かない。


あたりでしょうか。Larrabeeとかどうなるんかなぁ。
posted by chun at 00:00| 日記