昨日某君のコードを似鳥君が見て、いくつかの計算量が多いループについてこ う変形、というのを指示しているところを見物させてもらう機会がありました。 実際の主な作業は、コードを書換えてコンパイラにかけ、メッセージをみてベ クトル化、アンロールされているかどうかを確認することであり、コンパイラ がベクトル化とアンロールの両方に成功したというようになったら、アセンブ ラ出力をチェックして問題のループに対応する部分で確かにSIMD 命令がでてい るかどうかを確認、それから実行してその部分の詳細プロファイルをとり、4命 令発行が十分多くなっていることを確認する、というような手順になります。

コードの具体的な書換えの例を以下に2つほど。実際のソースは今手元にない ので感じだけです。なので、実際にこの形のものというわけではない です。

例えばループ内で計算結果や配列のデータによっ て処理が変わる、例えば

  do i=1, n
     if (a(i) .gt. 0.0) then
        b(i)=xxx
     else
        b(i)=zzz
     endif
  enddo

  do i=1, n
     if (a(i) .gt. 0.0) then
        btmp=xxx
     else
        btmp=zzz
     endif
     b(i)=btmp
  enddo

また、 if then else endif の代 わりに可能な場合には最大値関数を使うのも有効とのことでした。

あと、F90の配列記法を使った文、つまり、ベクトル化可能と明示的に書いてあ るものが性能がでなくて、 DO ループにしたらちゃんと性能がでるようになったとかいう例もありました。

こういうのは25年前にベクトル化コンパイラを使っていた私にはなんだかとて もみおぼえがある書換えで、結局、近代的な SIMD マシンで SIMD ユニットの 性能がでるためにはまずはベクトル化できるように書くということになります。 で、そのためにはコンパイラが理解できるようにソースを書換える必要がある わけです。必要な書換えは、25年前にベクトル化コンパイラ相手にやっていた のとあまりかわりません。

ベクトル化コンパイラの相手、というのは正直なところあまりやりたくない仕 事です。コンパイラに理解できるようにするためだけにコードを良く分からな い形に書換えていく必要があるし、それは要するにコンパイラのベクトル可能 性認識アルゴリズムに合わせる、というもので、しかもそれがどういうものか の明確な規則はドキュメントに完全な形では存在せず、 試行錯誤して 結果をみる必要があるからです。

さらに、それだけでは不足、というのが最近のマシンの厄介なところで、 キャッシュメモリはちゃんと使えているか、といったことが次には問題に なってくるわけです。

25年前に比べて、MPI で並列化して書くというだけで恐ろしく大変になってい るのに、1ノード内でのチューニングもベクトル化的なことはしないといけな いしキャッシュも考えないといけないわけで、なかなか手に負えない 代物になってきているのを実感しました。