makeこの方法だとコンパイルと実行はできるが、途中でフリーズする。止まっているので、SPEの方とうまく同期が取れていない模様。↑SPEの数を7と設定しているのが問題。6などのように6以下の数にしたら解決。ps3a.yuba.is.uec.ac.jp編集ps3a.yuba.is.uec.ac.jpで簡単に動かせるようにちょっと変えたtoolkit0.5をおいておきます。run1とかやればすぐ動きます。お役にたてば幸いです(もうすぐ正式版もリリースされますが)。例にならってツールキットver.1.0.xのps3a版。0.9983098およそ0.16〜0.73%の性能向上が見られた。(2009/2/2追記)良くなる要因DMA転送量が減る(dmaget()関数を呼ぶ回数が減る)悪くなる要因PPEはすぐにSPEに仕事を割り振らず、キャッシュの使えるSPEを探してから割り振る。その間に止まり続けるSPEが少なくとも1つある。SPEはキャッシュが使えるかどうかを判定してからDMA転送する。条件分岐による遅延があるかもしれない。前回の結果が微々たる変化だったので、本当に性能向上してるか疑わしい。同じ検証を何度か繰り返したところ、性能が低下することも何度かあった。キャッシュを利用してDMA転送を省略する回数をrun3を用いて調べたところ、ばらつきはあるが1/500(=50回/25600回)程度の割合だった。そのために、良くなる要因が活きないと考えられる。文字列の長さnum1が20480以上である場合、ブロック数bnum1を(num1/64)とする。ブロックサイズ変更のプログラムは、本ページの「ブロックサイズの変更による性能変化」を元にしている。1.8008777%から80%計算時間が長くなってしまっている。計算できないキューは通常通りenqueueするが、計算できるキューは次にもう一度取り出せるように戻す(push)。spe1.c-skew-v1.tar.gz(10)SPEが内部に持つ128x128の配列を、次のような斜め方向の順番で保持するように変更した。大島さんのSIMD化と久米君のmin関数の改善案を参考にしている。16383実行時間の比較を行った。0.923大体で実行時間が短くなった。SIMD用のAPIはまだ使ってないが、イタレーション内の並列性が増したのでうまく最適化してくれてるのかも。CellOpenCafeで動かしたところ、改善が見られなかった。0.133016最小値と最大値の幅が100msec程度あり、ps3aに比べて非常に大きい。性能向上は1%から2%程度みられた。(少ない...)ためしにSIMD化する前のものをOpenCafeで動かしたが、性能向上は見られなかった。ps3aでよくなっても、必ずしもOpenCafeで同じように改善するとは限らないようだ。0.12337446ps3aでも簡単に比較したところ、その2よりさらに性能向上していた。0.80sec→0.65secぐらい)ただしソースの可読性は反比例して悪くなった。0.65sec→0.50secぐらいまで向上した。ppecalc-1-ppe.c(13)PPE上で計算するスレッドを1つ走らせる。0.029006720あまり有効でないようだ。編集どれくらい高速になったかを簡単に調べた。0.26406312SUCCESSFUL.プロセッサ数が6倍で、計算時間は約0.178倍(逆数は5.6程度)なのでかなり良い並列化ができている。ver.1.0より大幅に高速化することは難しそう...。編集SPEが計算する部分行列は128x128がデフォルトだが、そのサイズを変更したら性能はどのように変化するかを調べた。1.826この結果を見ると、最適なブロックサイズはサンプルデータによらず、1600分割(40x40分割)〜6400分割(80x80分割)あたりに良いブロックサイズがあるように見える。