月別アーカイブ: 2023年6月

ROG Ally Zen4 vfpbench の結果

ROG Ally で Z1 Extreme (Zen4) に触ることができたため vfpbench の結果を調べました。ポータブル機でも 8 core あるため基本性能が高く、CPU だけでも単精度で 1 TFLOPS を超えています。

SingleThread SP max: 137.726 GFLOPS
SingleThread DP max: 68.841 GFLOPS
MultiThread SP max: 1120.448 GFLOPS
MultiThread DP max: 603.461 GFLOPS

また Zen4 は AVX512 に対応しています。AVX512 は bit 幅だけでなくレジスタ本数も倍増しており、AVX(256bit) と比べるとレジスタだけで 4倍のデータ量を扱うことができます。

Zen4 は 256bit の積和と 256bit 加算パイプラインをそれぞれ 2本の合計 4本備えています。そのため FMA だけなら同時に 2命令実行可能なので、理論上のピーク性能値は

8(avx) x 2(fma) x 2(pipe) x 8(core) x 3.3(clock) = 844.8 GFLOPS

となります。
vfpbench の結果を見ても単コアで fma の IPC が 2 です。(A)

                                      TIME(s)   MFLOPS      MOPS     FOP   IPC
FMA vfmaddps (32bit x8) n12       :    0.459   103632.4     6477.0  ( 16.0 2.0) -- (A)

ただしこれだけでは 844.8 GFLOPS であり 1 TFLOPS に届きません。

Zen 4 は積和の他に加算パイプも 2本あるため、積和命令と並行して加算命令も実行させられる可能性があります。

実際に mul + add の組み合わせ (B) では 3.9、ほぼ 4命令同時に走っておりピーク FLOPS 値が fma x2 とほぼ同等になっています。

                                      TIME(s)   MFLOPS      MOPS     FOP   IPC
AVX vmul+addps (32bit x8) n8      :    0.152   104158.5    13019.8  (  8.0 3.9) -- (B)
FMA vfma+adps (32bit x8) n12      :    0.322   110800.7     9233.4  ( 12.0 2.8) -- (C)
FMA vfma+mlps (32bit x8) n12      :    0.458    77839.3     6486.6  ( 12.0 2.0) -- (D)

同じように fma + add の (C) も IPC が 2を超えるのですが、2.8 とおよそ 3命令、1.4 倍にしかなりませんでした。それでも FOP が 3/4 で IPC が 1.4 倍なので、FLOPS 値も fma x 2 の (A) より (C) の方が上がっています。これで 844.8 GFLOPS を超えられます。

なお乗算命令は積和と同じ実行パイプを使用するため、fma + mul の組み合わせ (D) では IPC が 2のまま変わりません。

まとめると、256bit の場合 乗算+加算の場合は最大 4、積和が含まれる場合は最大 3命令同時に実行できる可能性があります。

この結果は Zen2 とは異なっています。Zen2 でも 256bit 積和 + 加算 がそれぞれ 2本の合計 4本で構成は同じですが、mul + add のケースでも最大 3命令、fma + add では 2命令までしか実行できませんでした。

AVX512 の結果を見ると、やはり 512bit では fma (E) は同時に 1命令になっています。よって fma だけのピーク FLOPS は 256bit fma x2 と変わりません。

                                      TIME(s)   MFLOPS      MOPS     FOP   IPC
AVX512 vfmaddps (32bit x16) n12   :    0.916   103842.0     3245.1  ( 32.0 1.0) -- (E)
AVX512 vfma+aps (32bit x16) n12   :    0.518   137726.3     5738.6  ( 24.0 1.7) -- (F)

ですが、fma + add の場合 (F) は約 1.8命令 (0.916/0.518 = 1.768) あり、256bit AVX の 3命令時よりも並列度が上がっていることがわかります。仮に同時に発行できる命令数が 3 op に制限されていても、AVX512 ならその影響を受けづらいということでしょうか。

現在の vfpbench には 512bit の add + mul の計測値が含まれていないので実際は不明ですが、Zen4 の場合 AVX512 の 512bit 命令でも 乗算+加算 の組み合わせは同時に 2命令実行できる可能性があります。

今回の計測値で最も高い数値が出ていたのは AVX512 512bit の fma + add の場合です。24/32 * 1.768 * 844.8 GFLOPS = 1120 GFLOPS

まとめると、

  • Zen4 は Zen2 よりも同時に実行できる fp 演算命令数が多い
  • Zen4 では 256bit 命令よりも AVX512 512bit 命令の方がピークの演算能力が高い

もちろん実際のアプリケーションで理論上の性能が出るわけではありませんのでご了承ください。

なお Intel IceLake の場合は 256bit 積和 x 2 の実行パイプなので、256bit 未満で最大 2命令、AVX512 の 512bit では同時 1命令になります。
詳しくはこちら

blog 移行

サーバー側の事情があり、Nucleus から WordPress へ移行を行いました。

データの移行には変換スクリプトを作成して、REST API で書き込んでいます。変換したのは blog の記事 (item) と画像、category、そして comment です。

●前回の移行

blog 移行は 2回目です。

前回 blog データの移行を行ったときは外部 blog だったので、直接データベースにアクセスすることができませんでした。export ツールはあったものの、出力テキストには記事 id が含まれていないために自分自身へのリンクがどの記事を指しているのかわかりません。

そこで自分自身へのリンクを解決するために、script から http で直接旧 blog のページにアクセスし、日付情報を取得してリンク先を解決する方法を取りました。

その経験から、自分自身へのリンクは blog 固有の記事 id ではなく、できるだけ日付で行うようにしていました。1日1投稿の制限を守れば、id が分からなくてもリンク先の記事が特定できるためです。

●今回の移行

今回は直接データベースにアクセスできるため、変換自体は問題ありませんでした。記事 id (item id) を使ったリンクでも問題なく置き換えできており、日付で自己参照していた意味はありませんでした。

ただし今回は同じサイトということもあり、できるだけ Nucleus 時代の固有 URL を維持するように心がけました。Nucleus の記事 id を WordPress の slug (n+番号) として登録して、従来の記事 id でも容易にアクセスできるようにしています。

実際の置き換えそのものは mod rewrite で行っています。

例えば Nuclues の ~/item/番号 のリンクの変換は

RewriteRule ^item/(\d+) n$1 [R=301,L]

となります。

同じように Nucleus 時代のリンクがエラーにならないよう、archive の日付、category の番号、query を使った「?itemid=番号」や「?virtualpath=」なども変換を行っています。

RewriteCond %{QUERY_STRING} ^virtualpath=(.*)$
RewriteRule ^(.*)$  %1/? [QSD,R=301,L]
RewriteCond %{QUERY_STRING} ^itemid=(.*)$
RewriteRule ^(.*)$  n%1/? [QSD,R=301,L]
RewriteRule ^archive/1/(\d+)-(\d+)-(.*)$  $1/$2/$3 [R=301,L]
RewriteRule ^category/(\d+)  category/cat$1 [R=301,L]

実際に使用したスクリプトをこちらに上げておきます。

https://github.com/hiroog/nucleustowp