これがキャッシュありになるととたんに話がややこしくなって、まず右辺の 差分が i 方向だとSIMD 幅でアラインしていないので、レジスタ内でのローテー トや理想的にはレジスタ2本から任意の場所を切り出すという命令が必要で、 レジスタの本数が少ないとさらにメモリアクセス自体も増えます。

j方向の差分では、 j-1 の時と j の時でアクセスする配列がオーバーラップ するので、それが L1キャッシュにはいる程度に最内側ループが短いと原理的には性 能がでますが、最内側ループが短いと「京」では性能がでないという問題もあ ります。まあ、「京」に限ったことではないですが「京」では特に大きな問題でした。

ここでの問題は、SIMD 幅が広くなる、ということは、最内側ループの反復回 数がそれだけ小さくなる、ということに直結する、ということです。例えば、 最内側ループ長が256だった時、「京」での実際の繰り返し回数は64ですが、 単精度32演算のマシンではわずか8になり、ループ長が短くなりすぎます。 一方、L1やL2のサイズはSIMD幅が大きくなっても増えないし、バンド幅は なんとか減らさなかったとしてレイテンシは増える方向にいきます。

「京」では、このために i 方向のサイズを大きくして(空間分割を直方体形状 にする)、なんとか性能がでるようにする、というアプローチをとっている場 合が多いです。これは、メインメモリのバンド幅が B/F で実効0.35 程度はあ り、上のループで十分な再利用ができて1要素の計算につき 1 load, 1 store 程度になれば名目ピークの20%程度はでるからです。しかし、SIMD幅が 8倍とかメインメモリのバンド幅が相対的に半分とかになると、実行効率が 1/2ないし 1/3 程度に低下してしまうことになります。

実行効率が主記憶バンド幅依存になれば、ハードウェアの B/F が下がると必 ず性能は下がるわけで、なんとかするには主記憶依存にならないようにするし かありません。具体的には、 L2 にはいるサイズ程度で計算して、時間方向に 複数タイムステップ進める、最近は temporal blocking と呼ばれるらしい方 法を使う必要があります。

これは原理的には美しいのですが、上で述べた、最内側ループが短くなる、と いう問題は必然的に発生します。おそらく、コンパイラに対しては、 最内側ループは手で(あるいは自動生成で)完全にアンロールし、さらに その次のループまでアンロールしたコードを渡す必要があるでしょう。また、 横との通信も、メッセージサイズが短くなるため、低レイテンシであることが 必須となります。レイテンシ3マイクロ秒とかでは論外で、1マイクロ秒を大き く切らないと、というのが色々なコードででてくる見積もりです。

なお、上のような、最内側の次のループの展開だけでは、L2 の再利用しかで きなくてL1 の再利用は k 方向の微分ではできません。k 方向の 微分については、配列の j,k 方向での転置を行えば、ループ本体での L2 ア クセスは減らすことが原理的には可能です。

そういうわけで、「汎用」プロセッサでは世代が変わる毎にSIMD幅が広くなっ たり、相対的にメインメモリやキャッシュのバンド幅が下がったりレイテンシ が増えたりするので、そういったものに依存したチューニングがされているコー ドの実行効率はプロセッサの世代が変わると必ず大きく低下します。歴史的に は、SIMD が導入された Pentium 4 でそういうフェーズにはいり、それがすで に10年以上続いているわけです。

まあ、ソフトウェアが大事だとかいって人件費をとるにはこういうアプローチ がいいのかもしれないのですが、こういう、賽の河原で石を積むようなことを 将来ある若い人にやってもらうのは好ましいことではないと私は考えます。

何がいいたいかというと、こういう問題に対してもうちょっと一般化したアプ ローチをするべきである、ということです。具体的には、というのはすでに この文章の前のほうに書いたわけですが、、、

Previous

ToC

Next