IvyBridge と N100 を比較する

OS サポートが切れた 12年前の Mac mini をずっと Linux マシンとして使用していましたが、今なら Intel N100 の方が速いのではないかと思い速度を比べてみました。N100 は AlderLake (第12世代) の E-Core のみ搭載した CPU です。

以下は Ubuntu 22.04 におけるコンパイル時間 (clang 14) を比較したものです。

PCCPUTDPClockCoreThreadコンパイル時間
Mac mini Late2012Core i7-3615QM45W3.3GHzIvyBridge4C 8T69.57
Mini PCIntel N10020W3.2GHzAlderLake(E)4C 4T59.67
  • ↑コンパイル時間の数値が小さい方が高速

ストレージもメモリもクロックもちょうど同じくらいの性能でしたが、N100 の方が 10秒ほど早くビルドが終わっています。N100 は Atom 系の省電力コアながら、第3世代 Core の IvyBridge よりも速いことがわかります。

搭載されているメモリとストレージは以下の通りです。

PCCPURAM 容量メモリの種類メモリ速度STORAGE
Mac mini Late2012Core i7-3615QM16GBDDR3-1600 x225.6 GB/sSATA SSD
Mini PCIntel N10016GBDDR4-3200 x125.6 GB/sSATA SSD

なお N100 の TDP はスペックを見ると 6W ですが、テストした PC の UEFI (BIOS) では PL1=20W, PL2=無効 に設定されていたため今回の結果は 20W 時の値になっています。

さらに N100 で vfpbench の値も調べてみました。IvyBridge と比較してみます。

PCCPUTDPClockSingle SpSingle DpMulti SpMulti Dp
Mac mini Late2012Core i7-3615QM45W3.3GHz51.7G26.1G193.4G97.0G
Mini PCIntel N10020W3.2GHz54.2G27.1G185.0G92.6G
  • ↑数値の単位は FLOPS、値が大きい方が高速

すべての結果は以下の場所にあります。

掲載した表の数値はピーク値のみです。これを見るとどちらもあまり差が生じていないように見えますが、その内訳は大きく異なっています。

IvyBridge は 256bit の浮動小数点演算パイプを 2本持っており、それぞれ加算と乗算を受け持ちます。FMA には非対応ですが AVX 256bit の add と mul 命令を同時に実行できるため、この組み合わせがピーク値になります。add または mul 命令単独の場合は片方のみが使われるため効率は半減します。

N100 は FMA に対応しているため 1命令で積和演算が可能です。その代わり 256bit の AVX 命令はクロックあたりひとつしか実行できず、256bit fma がピーク値になります。128bit の AVX/SSE であれば 2命令実行できているため、浮動小数点演算の実行パイプラインは 128bit が 2本あることがわかります。この構成は AMD の Jaguar 系と似ています。

これらの結果より FMA や AVX2 があるので互換性の面でも N100 が有利ですが、fma 以外の 256bit AVX 浮動小数点演算が混在するようなケースでは IvyBridge の方がスループットが高くなる可能性があります。

大まかに両者の性能がわかったところで、他の PC ともコンパイル時間を比較してみたいと思います。

以下の表は同じ Linux 上での比較です。Ubuntu 22.04 Clang 14。SteamDeck は Distrobox を使用しています。

PCCPUTDPThreadCoreSTORAGEコンパイル時間
Mac mini Late2012Core i7-3615QM45W4C 8TIvyBridgeSATA SSD69.57 秒
Mini PCIntel N10020W4C 4TAlderLake(E)SATA SSD59.67 秒
SteamDeck LCDCustom APU 040515W4C 8TZen2NVMe 452.31 秒
Desktop PCRyzen 5 260065W6C 12TZen1+SATA SSD29.78 秒
  • ↑コンパイル時間の数値が小さい方が高速

以下の表は同じ Ubuntu 22.04 Clang 14 ですが Windows 上の WSL2 を使用しています。同じ N100 や Ryzen 5 2600 で比べるとわかるように、Native の Linux よりも若干遅めの数値になります。

CPUTDPTHREADCORESTORAGEコンパイル時間
Intel N10020W4C 4TAlderLake(E)NVMe 367.26 秒
Core i5-940065W6C 6TCoffeeLakeNVMe 355.86 秒
Core i7-4790K88W4C 8THaswellSATA SSD39.77 秒
Core i7-6700K65W4C 8TSKyLakeSATA SSD35.83 秒
Ryzen 5 5560U25W6C 12TZen3NVMe 335.04 秒
Ryzen 5 260065W6C 12TZen1+NVMe 332.10 秒
Ryzen 5 360065W6C 12TZen2NVMe 322.78 秒
Ryzen 7 4750G45W8C 16TZen2NVMe 322.36 秒
Ryzen Z1 Extreme25W8C 16TZen4NVMe 417.33 秒
Ryzen 9 3950X105W16C 32TZen2NVMe 39.17 秒
Core i7-1370065W16C 24TRaptorLakeNVMe 48.39 秒
  • ↑コンパイル時間の数値が小さい方が高速

やはりコア数が多い CPU や新しいアーキテクチャの CPU、消費電力の高い CPU は性能が上がります。

下の表はさらに Android 上の Termux (Clang 18.1.7) での計測してみた結果です。モバイルデバイスも CPU もコア数が多いので今回のケースでは速度が出ています。ただし RAM 容量が少ないことや放熱の問題があるので、大きなプロジェクトや長時間の連続稼働にはおそらく向きません。

PCCPUTHREADCOREコンパイル時間
iPlay 50 Mini ProHelio G998C 8T (2+6)A76 / A5553.68 秒
iPlay 50 ProHelio G998C 8T (2+6)A76 / A5547.45 秒
Huawei P30 ProKirin 9808C 8T (4+4)A76 / A5527.73 秒
Pixel 8aTensor G39C 9T (1+4+4)X3 / A715 / A51021.94 秒
Pixel 8Tensor G39C 9T (1+4+4)X3 / A715 / A51020.35 秒
  • ↑コンパイル時間の数値が小さい方が高速

N100 搭載 PC は安価で入手できることもあり人気があります。Raspberry Pi 5 を一通り揃えても同じくらいの価格帯になりますので、入手のしやすさは魅力といえます。IvyBridge の Core i7-3615QM との比較でも十分 N100 の方が速いことがわかりました。

ただし思ったよりも差は少なく、他の PC と比べると性能には限界があります。もし少ない価格差で Ryzen 5 5560U にアップグレードできるならビルド時間は約半分、浮動小数点演算性能も数倍になりますので、用途によってはこちらの方がコストパフォーマンスは良いかもしれません。

関連エントリ

SteamDeck の Linux Desktop で日本語入力環境を作る

前回 SteamDeck には簡単に Linux 環境をインストールできることがわかりました。SteamOS には最初から distrobox コマンドがインストールされており、コマンド一つで各種 Linux 環境を入れることができます。

例えば Ubuntu をインストールするならコマンドラインから「distrobox create -i ubuntu:22.04」のように実行するだけです。apt 経由で各種ソフトウエアを利用できるので開発環境の構築なども簡単です。またインストールした環境はコンテナなので、失敗しても削除できますしすぐやり直すことができます。気軽にテストすることができます。

今回は Debian で GUI の日本語入力環境を整えてみます。

先に USB または Bluetooth キーボードを接続しておいてください。マウスもあった方が良いですが、SteamDeck 右側のタッチパッド + R2(左クリック) / L2(右クリック) でも代用できます。

(1) SteamOS のデスクトップに切り替える

  1. 「STEAM」ボタン → 「電源」→「デスクトップに切り替え」

以降再起動でゲーミングモードに戻った場合は、再びこの操作でデスクトップに切り替えてください

(2) 日本語表示に切り替える

  1. デスクトップ左下の Application Launcher アイコン → Settings → System Settings
  2. Regional Settings → 一番上にある Language 右端の「Modify…」
  3. 「Change Language」→「日本語」を選択
  4. 右下の「Apply」→ 右上の「Restart now」→「OK」
  5. 再起動するので、再びデスクトップに切り替えておきます。

(3) キーボードを日本語配列に切り替える

接続したキーボードが日本語配列の場合以下の設定を行います。英語配列キーボードを使用していて不要な場合はスキップしてください。

  1. デスクトップ左下の「アプリケーションランチャー」アイコン → 設定 → KDE システム設定
  2. 入力デバイス →「レイアウト」タブを選択 → 「レイアウトを設定」にチェックを入れる
  3. 「+Add」ボタン → Search欄に「109」を入れて「日本語 (OADG 109A)」を選択 → OK
  4. もとからあった英語配列を削除します。”英語(US) ” を選択して「-Remove」ボタンで削除
  5. 右下の「適用」クリック → 設定ウィンドウを閉じる

(4) ホームディレクトリに .distroboxrc を作成

  1. デスクトップ左下の「アプリケーションランチャー」アイコンから「ユーティリティ」→「KWrite」を開く
  2. メニューの「ファイル」→「新規」
  3. 以下の内容を書き込む
xhost +si:localuser:$USER
export PIPEWIRE_RUNTIME_DIR=/dev/null
  1. メニューの「ファイル」→「名前をつけて保存」
  2. 左上の「場所」の中から「ホーム」をクリックして選択
  3. 下の「名前(N):」の欄に「 .distroboxrc 」と入力
  4. 右下の「保存(S)」をクリック
  5. KWrite のウィンドウを閉じる

(5) ホームディレクトリの .bashrc を編集

  1. 画面左下のアプリケーションランチャーアイコンから「ユーティリティ」→「KWrite」を開く
  2. メニューの「ファイル」→「開く」
  3. 下の「名前(N):」の欄に「.bashrc」を入力して右下の「開く」をクリック
  4. 一番下に以下の内容を入力
export LANG=ja_JP.UTF-8
export DefaultIMModule=fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
  1. メニューの「ファイル」→「保存」を選択してから KWrite のウィンドウを閉じる

(6) ターミナルから Debian をインストール

  1. 画面左下のアプリケーションランチャーアイコンから「システム」→「Konsole」を開く
  2. ターミナル (Konsole) 内で以下のコマンドを実行
    • (“$” はプロンプトを意味するので、$ を除いた空白以降 “distrobox create ~” 部分を入力して Enter を押します。以後同じです)
$ distrobox create -i debian:12 -n debian
  1. “Do you want to pull the image now? [Y/n]:” と表示されたら「Y] を入力

(7) Debian 環境に入る

  1. 同じようにコンソールのコマンドラインから以下のように実行します。
$ distrobox enter debian

初回はインストールが入るので時間がかかります。

Debian 環境に入るとプロンプトが「(deck@steamdeck ~)$」から「deck@debian:~$」に変わります。

(8) Debian 上で環境構築

以後同じプロンプト「$」で表現していますが Debian に入った状態で行います。

  1. 以下のコマンドを実行します
$ sudo apt update
$ sudo apt upgrade -y
$ sudo apt install -y locales
$ sudo dpkg-reconfigure locales
  1. 言語選択画面になるので、キーボードから [j] キーを入力
  2. ja_JP.UTF-8 が選択されているので [SPACE] キーを押して選択状態にします (“*” マークが付きます)
  3. 同時に下段の < OK > が選択されているはずなので、そのまま [Enter] を 2回押して終了します
  4. 同じようにコンソールから以下のコマンドを実行します
$ sudo apt install -y task-japanese
$ sudo apt install -y fonts-noto-cjk
$ sudo apt install -y fcitx-mozc
$ fcitx

これで Debian 側でインストールしたアプリケーションは日本語入力が可能になります。

(9) キーボード配列の設定その2

タスクバーの右下あたりにキーボードのアイコンが追加されていることを確認します

  1. タスクバーにあるキーボードのアイコン右クリック→「設定」
  2. 「入力メソッド」のタブに、以下のように Mozc が並んでいれば OK です
キーボード - 日本語 - 日本語(OADG 109A)
Mozc

  1. もし日本語キーボードを使用しているのに、上の段が「キーボード ~ 日本語 (OADG 109)」になってない場合は切り替えてください
    • 画面下の「+」ボタンから新たに「日本語」配列を追加して、「-」ボタンで不要なものを削除しておきます
  2. タブを「全体の設定」に切り替えます
  3. 入力メソッドのオンオフ」の部分で、日本語入力切り替え方法を確認します
    • デフォルトでは「Ctrl+Space」が設定されているはずです。
  4. 設定ウィンドウを閉じます

これであとは Debian 側でインストールしたアプリケーションは日本語入力ができます。日本語入力への切り替えは「Ctrl」を押しながらスペースキーです。

注意点としては、デスクトップ左下のアプリケーションランチャーからは起動できず、Debian のコマンドラインから起動する必要があります。またこの手順では自動起動のの設定をしていないので、再起動後は手動で fcitx を起動する必要があります。

再起動後やゲームモードから切り替えた場合に再び Debian 環境に入る手順

  1. Konsole を起動し、ターミナル内で「 distrobox enter debian 」を実行
  2. Debian 環境に入ったらコマンドラインで「fcitx」を実行

タスクバーにキーボードのアイコンがない場合は手動で fcitx を起動してください。

以下アプリケーションごとのインストール例

あくまで例なので必要に応じてどうぞ。

Firefox

Debian 環境に入った状態で以下のようにインストールします。インストールが終われば firefox コマンドで起動できます。この firefox 上では [Ctrl] + [SPACE] で日本語入力ができます。

$ sudo apt install -y firefox-esr
$ firefox

起動時に「KDE ウォレットサービス」の画面が表示された場合はとりあえずキャンセルします。

なお、この Firefox は SteamOS 側のアプリケーションランチャーやタスクバーからは起動できないので注意が必要です。必ず distrobox enter debian で Debian 環境に入ったあとに、コマンドラインから firefox を起動してください。

Chrome

  1. firefox で Chrome for Linux をダウンロードします。「64bit .deb (Debian/Ubuntu 用)」を選択します
  2. ダウンロードしたファイルは Downloads フォルダに入っているので、Debian 環境に入ってからコマンドラインで以下のようにインストールします
$ sudo apt install -y $HOME/Downloads/google-chrome-stable_current_amd64.deb
$ google-chrome
  1. インストールが終わったら「google-chrome」コマンドで起動できます

gnome-terminal

  1. Debian 環境に入ってからインストールします
$ sudo apt install -y gnome-terminal
$ dbus-launch gnome-terminal
  1. ターミナルを起動するには「dbus-launch gnome-terminal」コマンドを実行します

Debian 側から起動したこのターミナルでは日本語入力ができます

VSCode

chrome と同じようにブラウザ上で「~.deb」ファイルをダウンロードし、「apt install 」コマンドでインストールします

  1. firefox で https://code.visualstudio.com を開いて 「.deb」ボタンから VSCode をダウンロードします
  2. ダウンロードが完了すると Downloads フォルダに入っているので、apt コマンドでインストールします (バージョンによってファイル名は異なります)
$ sudo apt install -y $HOME/Downloads/code_1.85.2-1705561292_amd64.deb
$ code
  1. インストールが完了したら、code コマンドで起動できます。もちろんテキストエディタとして普通に日本語入力できます。

Distrobox の管理

SteamOS 側のコマンドライン上で管理できます。同時に複数の環境を実行しないよう、不要なものは stop しておいてください。

インストールされているコンテナの確認

$ distrobox list

実行中のコンテナの停止

$ distrobox stop debian

名前をつけて別の Debian 環境を作成

$ distrobox create -i debian:12 -n debian2

その他詳しくは公式サイトをご覧ください。

活用など

SteamDeck の SteamOS はタブレットやスマートフォンのように電源ボタンによるスリープができます。いつの間にか電源が入っていて知らないうちにバッテリーを消費しているなんてこともなく安定しています。バッテリーも TDP を 3W まで下げることができるので、色々使えるのではないかと思ってます。

関連エントリ

Intel CPU Core i7-13700 (RaptorLake) の vfpbench 結果

Core i 12世代 (Alder Lake) 以降の Intel CPU は P-Core と E-Core、2種類の異なる CPU Core を搭載しています。ARM 系 CPU と同じように必要な負荷に応じてこれらのコアが使い分けられます。

vfpbench では種類によって計測するコアを区別する必要があるのですが、AlderLake 以降の Intel の非対称コアを今まで正しく認識できていませんでした。今回 Core i7-13700 を入手し、ようやく対応できたので結果を載せてみます。なお Linux では非対称コアを識別しますが、WSL1 上では区別できていないのでご注意ください。

以下は Linux で実行した Core i7-13700 の結果です。

結果からわかるように P-Core のピーク値は AVX 256bit の fma x 2 になっています。ここまでは従来の Skylake/IceLake 系と同じですが、mul + add の組み合わせの場合に 3命令実行できていることがわかります。

Ryzen Zen3/4 のように fma + add の組み合わせにならないためピーク値には影響がありませんが、おそらく AlderLake 以降は最大で 256bit x 3 命令が実行できるように拡張されているものと思われます。

P-Core
AVX vmul+addps (32bit x8) n8      :    0.197   124487.7    15561.0  (  8.0 3.1)
FMA vfmaddps (32bit x8) n8        :    0.371   132011.8     8250.7  ( 16.0 1.6)
FMA vfmaddps (32bit x8) n12       :    0.442   165987.5    10374.2  ( 16.0 2.0)
FMA vfma+mlps (32bit x8) n12      :    0.442   124495.1    10374.6  ( 12.0 2.0)
FMA vfma+adps (32bit x8) n12      :    0.381   144625.0    12052.1  ( 12.0 2.4)

また AVX512 が使用できません。そのため本来は対応していたと思われる fp16 演算や bf16 命令などもなくなっています。VNNI はあります。

E-Core の場合はピークが AVX 256bit fma x1 となっており、サイクルあたりの演算能力は P-Core の半分となっています。128bit 以下の場合は 2命令走っているので、実行パイプラインそのものは 128bit が 2本になっていると思われます。

E-Core
SSE addps (32bit x4) n8           :    0.305    32258.5     8064.6  (  4.0 2.0)
FMA vfmaddss (32bit x1) n12       :    0.525    14067.6     7033.8  (  2.0 1.7)
FMA vfmaddps (32bit x4) n12       :    0.521    56609.3     7076.2  (  8.0 1.7)
FMA vfmaddps (32bit x8) n8        :    0.602    65431.3     4089.5  ( 16.0 1.0)
FMA vfmaddps (32bit x8) n12       :    0.902    65432.2     4089.5  ( 16.0 1.0)
FMA vfma+mlps (32bit x8) n12      :    0.914    48433.6     4036.1  ( 12.0 1.0)
FMA vfma+adps (32bit x8) n12      :    0.914    48434.4     4036.2  ( 12.0 1.0)
128 add128 mul128 fma256 最大256 add256 mul256 fma256 最大
P-Core22232223
E-Core22221111

関連エントリ

Windows 10 を使って Intel CPU でゲーム開発をしてはいけない理由

近年の Intel CPU はスマートフォンや Apple と同じような非対称な CPU Core を採用しています。高性能コアと呼ばれる P-Core と、高効率(低消費電力)コアである E-Core の組み合わせです。この非対称な構造は Core i の第 12 世代 (Alder Lake) から用いられており、Core i9 で比較すると以下のようになります。

CPU P-CoreE-Core合計コア数合計スレッド数
2021年Core i9-12900KAlderLake881624
2022年Core i9-13900KRaptorLake8162432
2023年Core i9-14900KRaptorLake Refresh8162432

P-Core はシングルスレッド性能が高く HT に対応しているものの消費電力が高く強力な冷却が必要になります。E-Core はピーク性能が低い代わりにコンパクトでより多くの Core を搭載できます。

Windows 10 が問題なのは、OS のスケジューラーがこの非対称な CPU コアの性能を引き出すことができずに著しく性能が落ちてしまう場合があるからです。

実際に Core i7-13700 を使用して Windwos 10 で UnrealEngine 5 のビルド時間を測定してみます。Core i7-13700 は Core i9-12900K 同様 8P + 8E の 16コア、24スレッドの CPU です。

CPUCoreCore数Thread数RAMSSDビルド時間比較
Core i7-13700RaptorLake162464GBNVMe 480分32秒↑遅い
Ryzen 5 3600Zen261232GBNVMe 377分46秒
Core i7-11700KRocketLake81632GBSATA68分46秒
Ryzen 9 3950XZen2163264GBNVMe 436分03秒↓速い
  • VisualStudio 2019、 UE5 5.1.1 の Development Editor をビルドしたときの時間の比較
  • ビルドにかかった時間が短い方が高速

ビルド時間で旧世代の CPU 「Core i7-11700K」に敵いません。Core i7-13700 は K 無し (65W) モデルということもありますが、同じ 65W でコア数が半分以下の CPU 「Ryzen 5 3600」にも負けていることがわかると思います。

Core i7-13700 のビルド速度が予想以上に遅くなっている原因はタスクマネージャーを見るとすぐに分かります。下はビルド中のタスクマネージャーをキャプチャしたものです。

↑ 本来 24スレッドあるはずなのに 1/3 の 8スレッドしか稼働していません。しかもこの 8 スレッドはちょうど E-Core の 8個分に相当します。

UnrealBuildTool (UBT) は 8 コアにしか割り当てられていないことを知らないため、本来の 24 スレッドと認識しています。ビルド中は 14 個ものコンパイラが起動しており、これがすべて E-Core 8個に押し込められてしまうわけです。

そこで、UEFI (BIOS) で E-Core を無効化して P-Core だけを使ってビルドしてみることにします。以下の表にその結果を載せています。E-Core を無効化するだけで 55分まで短縮されました。ビルドが 25分も早く終わります。

CPU コア数スレッド数RAMSSDビルド時間比較
Core i7-13700無変更162464GBNVMe 480分32秒↑遅い
Core i7-13700E-Core 無効化81664GBNVMe 455分43秒↓速い

原因と回避方法など

ビルド中のタスクマネージャーを見ると、コンパイラは「基本優先度」が「通常以下」(BelowNormal) の状態で走っていることがわかります。

Windows 10 のスケジューラはおそらく、優先度が「通常」(Normal) より低い場合に E-Core に割り当てる仕組みになっているものと思われます。実際に UE5 5.1.1 の UnrealBuildTool の設定値を書き換えて、プロセスの優先度を Normal まで上げるときちんと全部の CPU Core にタスクが割り振られるようになりました。

UnrealBuildTool だけでなく、同じ問題は他のツールでも発生します。例えばシェーダーのコンパイル (ShaderCompileWorker) も同様で、負荷が E-Core のみに集中することがわかっています。

この問題は Windows 11 を使うことで解決します。

WIndows 11 では低プライオリティのタスクが E-Core だけに割り当てられてしまうことが無く、優先度が「通常以下」(BelowNormal) の場合でもすべてのコアを使用してビルドを行います。ビルド速度の比較表に Windows 11 での結果を加えてみました。

CPU コア数スレッド数RAMSSDビルド時間比較
Core i7-13700Windows 10 無変更162464GBNVMe 480分32秒↑遅い
Core i7-13700Windows 10 E-Core 無効化81664GBNVMe 455分43秒
Core i7-13700Windows 11 無変更162464GBNVMe44分55秒↓速い

↑ Windows 11 にアップグレードするだけでビルド時間を 35分も短縮することができました。

タスクマネージャーでもきちんとすべてのコア、24スレッドが使われています。

なお、UE5 5.2 からは UnrealEngine 側でもこれらの対応が行われています。UnrealBuildTool (UBT) の ParallelExecutor 利用時は以下のように、CPU が非対称コアを搭載している場合、優先順位を「通常以下」(BelowNormal) ではなく「通常」(Normal) に設定するようになっています。

/// The priority to set for spawned processes.
/// Valid Settings: Idle, BelowNormal, Normal, AboveNormal, High
/// Default: BelowNormal or Normal for an Asymmetrical processor as BelowNormal can cause scheduling issues.
/// </summary>
[XmlConfigFile]
private static ProcessPriorityClass ProcessPriority = Utils.IsAsymmetricalProcessor() ? ProcessPriorityClass.Normal : ProcessPriorityClass.BelowNormal;

そのため Windows 10 でも UE5 5.2 以降はエンジンのビルド時間が短縮されるようになりました。ただしこれは根本的な解決ではなく、ツール個別の対応になるため注意が必要です。もし対応していないツールが存在する場合 (他の UBT Executor や分散ビルドなど) はやはりパフォーマンスが低下してしまう可能性があります。

Core i 12000 シリーズ (第12世代, AlderLake) が出たばかりの頃はまだ Windows 10 搭載 PC も出荷されていました。せっかく新しい PC に入れ替えたのに、ビルド時間がかえって遅くなってしまうなんてことがありました。

流石に今はもう無いと思いますが、Alder Lake 以降の Intel CPU 上でゲーム開発を行う場合は Windows 11 を使用することをお勧めします。

Ryzen Zen3 の vfpbench 結果

Zen4 と順序が逆になりましたが Zen3 の結果も手に入れることができました。モバイル向け APU、Ryzen 5 5560U です。

実行ユニットは Zen2 同様 256bit の乗算(積和) x2 + 加算 x2 の構成です。そのため単純な fma 換算ではピーク値が Zen2 と変わらない fma x2 となるのですが、Zen3 の場合少々結果が異なります。

AVX vmulps (32bit x8) n8          :    0.172    64245.3     8030.7  (  8.0 3.5)
AVX vaddps (32bit x8) n8          :    0.172    64267.0     8033.4  (  8.0 3.5)
AVX vmul+addps (32bit x8) n8      :    0.086   128217.7    16027.2  (  8.0 7.0)
FMA vfmaddps (32bit x8) n8        :    0.214   103087.1     6442.9  ( 16.0 2.8)
FMA vfmaddps (32bit x8) n12       :    0.275   120290.1     7518.1  ( 16.0 3.3)
FMA vfma+mlps (32bit x8) n12      :    0.258    96422.6     8035.2  ( 12.0 3.5)
FMA vfma+adps (32bit x8) n12      :    0.172   144552.0    12046.0  ( 12.0 5.2)
AVX vml+ad+adps (32bit x8) n9     :    0.244    50965.1     6370.6  (  8.0 2.8)

fma x2 よりも fma + add の方が値が高くなっており、fma x 2 に加えて add も十分なスループットで回っているように見えます。ピーク値も追加の add 命令の分だけ上昇しています。パイプライン構成自体は大きく変わらないものの、Zen2 より命令発行数と実行効率が向上し、演算性能が上がっている事がわかります。

Zen4 の場合はこれに加えてさらに AVX512 にも対応します。fma だけ見ると違いがないように見えるかもしれませんが、世代毎に演算能力は上がっています。

関連エントリ