32コア64スレッドのCPUなんて、たった2年前までは“サーバーのためのCPU”“そんなCPUで何やるんだ”というような雲の上の存在だったが、この常識は2018年以降は通用しない。その理由は、第2世代Threadripperの最上位モデル「Ryzen Threadripper 2990WX」が登場したからだ。ひとつあたり8基のコアを持つZen+世代のダイを4基収容した2990WXは、実売23万円という高価格なCPUながら、メニーコア環境を構築したいコアユーザーに熱狂を持って受け入れられた。

Ryzen Threadripper 2990WX

しかし、発売と同時に2990WXは“暴れ馬”であることが判明する。あるアプリ（ベンチ）では猛烈に速いが、別のアプリではコア半数のThreadripper 2950Xと同等というもの。このあたりは筆者のファーストレビューでも検証済みだが、その原因は何なのか？これに対する有効な対策はあるのか？を考えてみたい。

Threadripper 2990WXの特異性

Threadripperファミリーは、2基または4基のダイをInfinity Fabricで結合させているのが最大の特徴である。ところが32コア64スレッドの2990WXと、16コア32スレッドの2950Xでは内部のトポロジーが大きく異なっている。まずはここを確認しておこう。

2950Xと2990WXの構造の違い

Threadripperには、4chのDDR4メモリーコントローラーと64レーン分のPCI-Expressインターフェースが搭載されているが、それらは2つのダイにのみ接続されている。2ダイ構成の2950Xの場合は、どのダイでも外部（ここではメモリーや拡張スロットを指す）にアクセスできる。しかし、4ダイ構成の2990WXの場合、外部にアクセスできるダイ（IOダイと呼ばれる）は2950Xと同じ2基のみで、追加された2基のダイ（コンピュートダイ）はIOダイを通じてアクセスする必要がある。

当然、コンピュートダイからメモリーへアクセスするには、レイテンシー的に不利になるので、コンピュートダイはメモリーアクセスが発生しにくい処理に使うべきだ。

さて、どのコアにどう処理を割り振るかはOSの仕事でもある。現時点でのWindows 10はIOダイとコンピュートダイを区別することができない。つまり2990WXが遅くなる原因は、OSにある可能性が否定できない。今後提供される予定のWindowsのOctober 2018 Updateにより、メモリーアクセスが改善され、メニーコアのパフォーマンスは向上すると言われている。実際に改善されるかは、今後確認していきたいが現状はパフォーマンスが上がらない。

ではどんなOSを使えばよいかだが、入手性やインストールの簡単さを考えればLinux、特にUbuntuやLinux Mint等の良く知られたディストリビューションということになる。特にLinux MintはUIの感じもWindowsに寄せてあるので親しみややすく、OSのコアの部分もUbuntuをベースにしているのでノウハウも集めやすい。

Linuxの中でもWindowsのGUIに寄せている「Linux Mint」を使用。UbuntuのGUIはやや前衛的なので、馴染みのあるGUIの方が良いだろう

Linuxのメジャーどころのアプリ（GimpやBlender等）は「Software Manager」を通じて導入すれば、Shellを立ち上げてコマンド操作する必要もない

2990WXをLinux MintとWidows 10で比較する

今回の検証において、Linux Mintは検証時における最新版「Linux Mint 19 Cinnamon」の64ビット版を使用した。Threadripper環境にLinux Mintをインストールする際の注意点は特にない。チップセット等のドライバーは標準のままで問題なく動作する。

また、使用したパーツは以下の通りだ。

GeForceのドライバー「ドライバマネージャ」を通じて提供されているものを使用。NVIDIA直だともっと新しいドライバーが手に入るが、こちらの方が気楽かつ（比較的）安定したものが使える

マザーボードは13フェーズ電源を備えたMSI製「MEG X399 CREATION」を使用した。これなら2990WXをフル回転させてもより安心して運用できるだろう

今回のテストはOSの差を見るのが目的なので、もWindows版とLinux版が用意されているアプリに絞って検証した。また、この条件をクリアーしても、Windows版とLinux版で設定の同一性が確認できないものや、同一でもエラーが出てしまうアプリは排除している。

まず2990WXレビュー時に判明したのは、Threadripperはレンダリングに滅法強いということだった。まず最初に「V-Ray Benchmark」のCPUレンダリング時間を比較する。

「V-Ray Benchmark」のCPUレンダリング時間

WindowsとLinuxでタイムは同じ。CGレンダリングはWindowsでも十分なパフォーマンスが出るということが示唆される結果となった。

ただし、CGレンダリングもアプリによって実装方法が違う。別のテストでの検証も必要だろう。そこで「Blender」のレンダリング時間を比べてみよう。現在Blenderにはベンチマーク専用アプリが開発中だが、今回はそれは使わず、公式ブログよりDLできる“Berbershop_Interior”をCPUでレンダリングするときの時間を比較する。

「Blender」Cycles Benchmarkより“Berbershop_interior”のCPUレンダリング時間

V-Rayと違い、BlenderではLinuxの方が30秒ほど早く終了した。どちらのOSでもCPU占有率はほぼ100％だったが、Linuxの方がより効率よく2990WXを使えるということだろうか。

次に動画エンコード系の処理で検証する。WindowsとLinux共通のソースから派生したエンコードツールとして「FFmpeg」を利用する。素材は再生時間約2分の4K H.264動画（M4V）であり、これをフルHDにダウンサイズしながらMP4ファイルに書き出す。コーデックはH.264とH.265の2通りで検証した。パラメーターは以下の通りとなる。

なお、Linux版のFFmpegはFFmpeg公式からダウンロードできるstatic版（必要なライブラリー等を組み込み済みのバイナリー）を利用している。

「FFmpeg」によるエンコード時間

OSがCPUのパワーを左右することがあるか？という問いに見事に答えてくれた結果といえるだろう。特にH.264の場合Windows環境の約半分の時間で処理を終えている。H.265を使うとその差は大分縮まるが、やはりLinux環境の方が2990WXの性能をより引き出せていると結論付けられる。

次に示す図は、FFmpegでH.264によるエンコードを検証している際にCPU占有率がどの程度あるのか比較したものである。CPU負荷は刻々と変化するため、スクリーンショット1枚きりで比べるのはかなり強引ではあるが、経時変化を観察し、可能な限り“よくある負荷分布”になったときの状態を比較するように努めた。

「FFmpeg」をWindows 10で実行したときのCPU占有率

「FFmpeg」をLinuxで実行したときのCPU占有率。各論理コアの占有率の左にある64個のボックスの色は、占有率の高さとは関係ない

Windowsは特定の論理コアの占有率が100％になる反面、それ以外の論理コアの負荷はほとんどかからないことが多い。今回の検証環境とFFmpegの場合、前掲のタスクマネージャーで2段め〜3段目（32コア分）処理が集中するのに対し、Linuxは負荷がバラける傾向にある。このCPUリソースの使い方の差が処理時間の差となって現れたといえる。ちなみに、各OSにおけるCPU占有率を単純に足し合わせた合計（64コアが100％フル稼働なら6400になる）は、Linuxが3944.7に対しWindows 10が3969と、そう大きな違いはない。特定コアにだけ負荷をかけるWindowsのスタイルを改善する必要がありそうだ。

次は同じ動画エンコーダーでもGUIのついた「Handbrake」で検証する。ソースの動画はFFmpegと共通のものを使い、H.264およびH.265での処理時間を比較する。H.264の画質設定はプリセットの「HQ 1080p30 Surround」を使用し、H.265はH.264の条件をそのまま継承したものとなる。

「Handbrake」による動画エンコード時間

FFmpegとは傾向が違うことがひと目でわかる。H.264に関してはLinuxの方がやや速いが、H.265についてはWindows 10の方がタッチの差で勝利。この程度なら誤差の範囲とも言えるが、必ずしもLinuxが2990WXのパワーを引き出せるという訳ではない。OSはあくまでベースで、その上で動作するアプリの対応も必要だ、ということになる。

FFmpegをWindows 10で動かすと、特定のコアのみに強い負荷がかかることが示された。今回の検証環境ではコア15から47までが100％になることが非常に多かった（コア0をタスクマネージャーの左上のコアとした場合）。

ではこの“負荷のかかるコア”に何か意味があるのだろうか？Windows 10環境でいくつかアプリで負荷をかけたときのタスクマネージャーの様子を以下に示す。

「Lightroom Classic CC」でRAW画像にシャープネス処理をかけつつJPEGに書き出す際のCPU占有率

「Media Encoder CC」でフルHDの動画をH.264のMP4形式でエンコードする際のCPU占有率

「Davinci Resolve」で4K動画をKakadu JPEG 2000 UHD-BDのIMF形式でエンコードする際のCPU専有率

高負荷をかけるとこのコアに負荷がかかる、という法則は一定ではない。今回の観測ではDavinciとFFmpeg/Handrakeでは完全に傾向が異なっている。動画エンコーダーのエンジンの特性と言ってよいだろう。動画エンコードはマルチスレッド処理が進んでおり……というのはせいぜい8〜16コア位までの話であり、それ以上になると急激に怪しくなることがわかった。

まとめ：2990WXを使うならLinuxが現状のベストチョイス

以上、簡単ではあるがOSの違いでThreadripper 2990WXのパフォーマンスが大きく違うこともある、ということが示せた。WindowsとLinuxでマルチで展開し、両方同じ条件でテストできるアプリが少ないのでややサンプルとしては物足りないかもしれないが、メニーコアCPUのパワーを扱うには、コンシューマー向けのWindows 10よりもサーバー用途等で様々なマルチプロセッサー環境へ展開されているLinuxの方が有利ということは明白だ。アプリを含めた環境をごっそり入れ替えるのは勇気のいることだが、Threadripperを手にしたなら、Linuxへ乗り換えることも有効ではないだろうか。

Threadripperの登場によって、アプリの開発者は、これまで想定しなかったスケールのマルチスレッド処理に対応することが求められるようになる。もちろん、今後32コアが全く並列にメモリー等にアクセスできるような化物CPUが出れば状況は変化する可能性もある。Threadripperは、CPUのパワー戦争を新たなステージへ押し上げようとしているのだ。

関連サイト

• AMD Ryzen Threadripper 2990WX
• AMD公式サイト