ツナ缶雑記

ぐうたらSEのブログです。主にマイクロソフト系技術を中心に扱います。

Seagate FireCuda 530 あらわる

f:id:masatsuna:20210813004406p:plain

2020 年末に構築した Ryzen 9 5900X 搭載の PC 、こちらには Seagate FireCuda 510 1TB の m.2 SSD を搭載しています。 詳細はこちらに書いている通りです。

tsuna-can.hateblo.jp

この記事でも書いた通り、 FireCuda 510 は仮想マシンのイメージ置き場として活躍してもらっています。 現状 3 台の仮想マシンを置いていて、同時起動しても問題ないレベルで使えています。 PCIe 3.0 接続ですが、性能的には十分満足できるレベルです*1

Seagate FireCuda 530

そんな中、なんと Seagate から FireCuda 530 がリリースされるというニュースが飛び込んできました。 520 から PCIe 4.0 接続ができるようになったものの、 I/O 性能は微妙で、価格帯も少々お高め、という割と謎な位置づけの製品でした。 530 はどんなもんかね、とスペック表を見てみると、 520 から大幅に性能向上している様子が見て取れました。

1TB モデルで比較するとこんな感じです。

項目 FireCuda 520 FireCuda530
シーケンシャル読取り 5000MB/s 7300MB/s
シーケンシャル書込み 4400MB/s 6000MB/s
ランダム読取り 760,000 IOPS 800,000 IOPS
ランダム書込み 700,000 IOPS 1,000,000 IOPS

データシート上は、 Samsung の 980 Pro とほとんど変わらない値になっています。 お値段も 26,000 円前後になるようで、十分戦える価格設定です。


あとこのモデル、なんと 4TB モデルが出るそうです。 4TB モデルの発売日は 2021 年 9 月 10 日で、まだもう少し先だそうです。 PCIe 4.0 対応、かつ高性能な 4TB モデルは今まで存在していませんでした。 両立を求める人には最適な選択になりそうです*2

メインの用途は PS5 の拡張用?

PS5 の拡張用 SSD の要件って結構厳しい仕様になっていますよね。 FireCuda 530 はこの要件にしっかり合致するものになっています。 しかも 4TB クラスの m.2 SSD で要件にあうのは FireCuda 530 くらいしかないんじゃないかと思います。 PS5 の拡張用 SSD としてのほうが、もしかしたら人気が出るかもしれませんね。

まとめ

あまり注目度の高くない SeagateSSD ですが、カタログスペック通りの性能が出るなら良い選択肢になりそうな気がします。 特に大容量モデルの登場は、うれしい人にはうれしいはずです*3。 誰かレビューしてくれないかな。

*1:仮想マシンのイメージ統合の速度が爆速になったのが本当にうれしい。安心してスナップショットとれる。

*2:その分値段が高いけど。

*3:主にPS5 ユーザーとか。

ASUS BIOSでTPMを有効にする

f:id:masatsuna:20210627182844p:plain

以前 MSIBIOS で、 TPM を有効化する方法について解説しました。

tsuna-can.hateblo.jp

今回は ASUSBIOSTPM を有効化する方法について解説します。 TPM が有効になっているかどうかは、 [tpm.msc] を用いて確認できます。 手順は以前の記事で詳細に解説しているので、そちらを参照してください。

環境

さすがにこの世代の物はもうほとんど流通していないので、最新世代の同等品へ製品リンクを張っておきます。



BIOS 設定

今回も、日本語化した BIOS での設定例を解説します。

PC を起動したら、 [Del] または [F2] キーを連打して、 BIOS の画面に入ります。 以下のような画面になります。

f:id:masatsuna:20210627181943j:plain

ASUSBIOS は起動すると EZ Mode で起動するので、 [F7] キーを押下して、 [Advanced Mode] に切り替えます。 続いて、画面上部のメニューから [詳細] を選択します。 そしてメニューの一覧から [PCH-FW Configuration] を選択します。

f:id:masatsuna:20210627182110j:plain

[Intel Platform Trust Technology] の項目を [Enabled] に設定します。

f:id:masatsuna:20210627182252j:plain

設定が完了したら、 [F10] キーを押下して設定を保存し、 PC を再起動しましょう。 これで TPM 2.0 が有効になります。

おまけ

ついでなので Windows 11 がインストールできるかも確認してみましょう。 以前の記事 同様、 [PC 正常性チェック] のアプリで確認します。 インストーラーは、 2021/06/27 現在、以下からダウンロードできます。

このアプリは現在新しくなっています。 記事内の画像は初期バージョンのものですのでご注意ください。

https://aka.ms/GetPCHealthCheckApp

このアプリを実行すると、以下のような項目が表示されます。

f:id:masatsuna:20210625192906p:plain

[今すぐチェック] ボタンを押下すると、システム要件のチェックが自動的に行われます。 TPM を有効にした状態でこのチェックを行うと、以下のように Windows 11 のインストールができると表示されました。

f:id:masatsuna:20210625193008p:plain

この PC も安心して Windows 11 のリリースを待てそうです。

Windows 11 のインストール手順

実際に Windows 11 を VM にインストールしてみました。 その際の手順や、 TPM 無効時の挙動などはこちらからどうぞ。

tsuna-can.hateblo.jp

Hyper-V の仮想マシンで TPM を有効にする

f:id:masatsuna:20210626192531p:plain

前回は物理マシンで TPM を有効にする方法について解説しました。 今回はその物理マシン上に立てた Hyper-V仮想マシンで、 TPM を有効にする方法を解説します。

環境

今回の記事で使用した環境は以下の通りです。

物理マシン(ホストOS)



仮想マシン(ゲストOS)

  • VHDX 形式の仮想ハードディスク(容量は可変)
  • 第 2 世代仮想マシン
  • 起動メモリは16GB(動的メモリは無効)
  • Windows 10 Pro 21H1(TPMの設定状態確認のためだけに使用)

物理マシンの方には、以下のメモリを入れています。 今回仮想マシンのメモリもふんだんに確保していますが、普通そんなに準備する必要はありません*1


設定方法

まずは上記の仮想マシンを普通に作成します。 今回は OS のインストールまで先に実施してから、以下の作業を行いました。

仮想マシンの作成が完了したら、ゲスト OS を一度シャットダウンし、ホスト OS の Hyper-V 管理画面で作成した仮想マシンの [設定] 画面を開きます。

[設定] 画面の左側メニューで [ハードウェア] > [セキュリティ] を選択します。 そして以下のように、 [トラステッド プラットフォーム モジュールを有効にする] のチェックをオンにします。

f:id:masatsuna:20210626164336p:plain

この状態で [OK] ボタンを押下して、設定を保存します。 これで設定は終了です(簡単)。

動作確認

作成&設定した仮想マシンを起動します。 前回の記事で解説した通り、 [tpm.msc] を起動して、設定状態を確認します。

f:id:masatsuna:20210626191216p:plain

問題なく TPM 2.0 が認識されていることを確認できます。

おまけ

ついでなので Windows 11 がインストールできるかも確認してみましょう。 前回の記事 でも解説した [PC 正常性チェック] というアプリを利用して確認してみます。 インストーラーは、 2021/06/26 現在、以下からダウンロードできます。

https://aka.ms/GetPCHealthCheckApp

実行してみると、以下のように問題なし、となりました。

f:id:masatsuna:20210626191521p:plain

これで物理マシンを傷つける(?)ことなく Windows 11 をお試しすることができそうです。

雑記

それにしても Windows 11 は、 CPU の要件が相当に厳しいですね。 徐々に拡大していくのか、このままなのか、よくわかりませんが、ここ 3 年くらいの間にリリースされたものしかリストにありません。

docs.microsoft.com

docs.microsoft.com

docs.microsoft.com

偶然、我が家の PC は入れ替えたばかりだったので問題ありませんでしたが。。。 ビジネスユースの PC の場合、結構古い PC を使っているケースも多いのではないかと思います。 私も昨年夏まで Core 第 6 世代の PC を会社で使っていましたし、まだ同じものを使っている人もたくさんいます。 そう考えると、特にビジネスユースの PC 入れ替えニーズが大きく高まることが予想されます。 昨今の半導体不足解消は、もう少し先になってしまうかもしれませんね。

*1:Windows 11 では最低 4GB あればよいそうです

MSI BIOSでTPMを有効にする

f:id:masatsuna:20210625194613p:plain

Windows 11 が発表されましたね。 システム要件がいろいろ変わっていく中で、 TPM 2.0 が必須になったというのも時代の流れを感じます。 企業向けのモバイル PC とかだと、 TPM 2.0 があらかじめ有効になっているケースも多いと思いますが、個人用の PC だと無効になっているケースも多いのではないでしょうか。

今回は MSIBIOS で、 TPM を有効にする方法を解説します。

なお本稿で解説するのは、ファームウェア TPM という機能を有効にする方法です。 ハードウェア TPM を用いる方法もありますが、個人利用の範囲であればファームウェア TPM で十分だと思います(そもそもデスクトップ PC だと多くの人が無効にしているのではないかと思います)。

なお ASUS BIOSIntel CPU)については以下で解説しています。

tsuna-can.hateblo.jp

環境



TPM の設定状態を確認する

まずは Windows 10 を立ち上げて、 TPM の設定状態を確認します。 以下のように [tpm.msc] を検索してアプリを実行してください。

f:id:masatsuna:20210625191209p:plain

TPM が無効状態の場合は、以下のような画面になります。

f:id:masatsuna:20210625191333p:plain

こうなってしまっている場合は、 BIOS から TPM を有効にします。

BIOSTPM を有効にする

PC を起動して [Del] ボタンを連打し、 BIOS に入りましょう。 MSI マザーボードの場合は [Del] キー連打ですが、メーカーが違うと [F2] 連打、とか、仕様が異なります。

以降の説明は、日本語化した BIOS で説明します。 MSI マザーボードBIOS を日本語化する方法は以下のポストで解説しています。

tsuna-can.hateblo.jp

BISO 画面に入ったら、 [F7] を押下して [Advanced] に切り替えましょう。 そして [SETTINGS] > [Security] を選択します。

f:id:masatsuna:20210625192112j:plain

続いて [Trusted Computing] を選択します。

f:id:masatsuna:20210625192151j:plain

[Security Device Support] の項目が以下のように [Disable] になっていると思います。

f:id:masatsuna:20210625192305j:plain

この項目を選択して、以下のように [Enable] に設定します。

f:id:masatsuna:20210625192344j:plain

設定が完了したら、 [F10] を押下して保存しましょう。

f:id:masatsuna:20210625192423j:plain

[はい] を押下すると、自動的に PC が再起動します。

再度 TPM の設定を確認する

再起動したら、再度 TPM の設定を確認してみましょう。 [tpm.msc] を検索してアプリを実行してください。 すると、以下のように TPM 2.0 が有効になったことが確認できます。

f:id:masatsuna:20210625192556p:plain

おまけ

ついでなので Windows 11 がインストールできるかも確認してみましょう。 Windows 11 のインストールが可能かどうかは、[PC 正常性チェック] というアプリをインストールすると確認できます。 インストーラーは、 2021/06/27 現在、以下からダウンロードできます。

このアプリは現在新しくなっています。 記事内の画像は初期バージョンのものですのでご注意ください。

https://aka.ms/GetPCHealthCheckApp

このアプリを実行すると、以下のような項目が表示されます。

f:id:masatsuna:20210625192906p:plain

[今すぐチェック] ボタンを押下すると、システム要件のチェックが自動的に行われます。 TPM を有効にした状態でこのチェックを行うと、以下のように Windows 11 のインストールができると表示されました。

f:id:masatsuna:20210625193008p:plain

これで安心して Windows 11 のリリースを待てそうです。

Windows 11 のインストール手順

実際に Windows 11 を VM にインストールしてみました。 その際の手順や、 TPM 無効時の挙動などはこちらからどうぞ。

tsuna-can.hateblo.jp

メモリの速度は.NETアプリケーションのビルド時間に影響を与えるのか

f:id:masatsuna:20210608201002p:plain

Ryzen シリーズの特徴として、メモリの速度が重要であると言われてきました。 様々なベンチマーク結果を見る限り、メモリの速度を上げることで、 CPU の処理性能を向上させることができているようです。 では実際の .NET アプリケーションのビルドというユースケースにおいて、メモリの速度がどの程度の影響を及ぼすのか調査してみた、というのが今回の趣旨となります。

環境

今回検証に使用するマシンは以下の通りです。

項目
CPU AMD Ryzen 9 5900X(PBO は自動に設定)
メモリ DDR4 32GB × 2枚(3200MHz)デュアルランク
記憶装置 1TB NVMe M.2 SSD(PCIe 4.0)
マザーボード MSI B550 TOMAHAWK
CPUクーラー Nocture NH-D15

この PC に対して、 BIOS でメモリの動作速度を変更し、その影響を確認します。 メモリ速度は、このメモリの SPD に記録されていた 2133MHz と、 Ryzen 9 5900X のサポートする最大値である 3200MHz を使用します。 3200 MHz の方は、XMP に入っている設定をそのまま使用します。 詳細は以下の通りです。

項目 SPD 設定 OC(XMP) 設定
速度 2133 MHz 3200 MHz
モリタイミング 15-15-15-36 16-20-20-38
電圧 1.2V 1.35V

なお使用しているメモリは以下のものです。


検証内容

検証は .NET 5 のアプリケーションをビルドし、ビルド時間を比較する方法で行います。 対象のソースコードは、 2021 年 5 月下旬に取得したものを使用します。 各アプリケーションは、 NuGet パッケージを参照しているため、事前にパッケージをすべてローカルにダウンロードした状態でビルドを行います。 ローカルファイル内にパッケージがあれば、ダウンロードする処理は行われないため、ネットワークの影響を限りなく無視することができます。

今回検証の対象となるアプリケーションは、以下の 2 つを利用します。

eShopOnWeb

github.com

こちらはマイクロソフト社が開発している .NET Core のリファレンスとなるアプリケーションです。 リファレンスとして使用するもので、プロジェクトの数も 9 つしかありません。

Entity Framework Core

github.com

.NET Core で使用できる代表的な O/R マッパーです。 こちらはそれなりに規模が大きく、 46 プロジェクトで構成されています。

検証手順

eShopOnWeb

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

dotnet restore eShopOnWeb.sln

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

dotnet build eShopOnWeb.sln

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 8 回ずつ実行します。

Entity Framework Core

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

restore.cmd

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

build.cmd

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 6 回ずつ実行します。

検証結果

eShopOnWeb のビルド時間

f:id:masatsuna:20210606074104p:plain

Entity Framework Core のビルド時間

f:id:masatsuna:20210606074117p:plain

結果を見てみましょう。 平均値で見比べると、やはりメモリの速度を上げることで、処理性能を引き出すことができるようです。 これまでの検証結果とも同じ傾向で、規模の小さなプロジェクトの場合はあまり影響を受けず、規模が大きくなるほど影響が大きくなります。

考察

今回はメモリの動作速度にだけ注目して検証を行いました。 Ryzen はメモリの動作速度が PC 全体のパフォーマンスに影響を与える、という説は、ここでも実証された形になります。

一般的にプログラムをコンパイルするという処理は、メモリを大量に使って処理を進める傾向にあります。 そのため、メモリのスピードを変更しただけでも、明らかにスピード差が生まれているものと推測します。 とはいえ、 CPU の差ほど大きな差がつくわけではないため、コストをかけるのであれば、まずは CPU を強化し、メモリは後回し、という考え方はいつも通り成り立つものと思います。

いずれにせよメモリの速度を上げることで、ビルド時間を多少でも短縮することができますので、チャレンジしてみる価値はあると思います。 なお私の PC に搭載しているメモリは、 3200MHz が最高設定ということになっているので、これ以上のオーバークロックは試していません*1。 メモリのオーバークロックによる効果も気になるところではありますが、今回の結果を見る限り、あまり大きな差は出ないものと思われます。

まとめ

今回は、メモリの速度が .NET アプリケーションのビルド時間にどの程度の影響を与えるか検証してきました。 CPU 程ではないにせよ、メモリの速度を上げることで、 .NET アプリケーションのビルド時間を短縮する効果が確認できました。 メモリの速度調整は、 XMP のおかげで比較的簡単に実施できます。 無理のない範囲でメモリ速度のチューニングを行ってみるのもよいかもしれませんね。

というわけで、今回で .NET アプリケーションのビルド時間を検証する企画は終了です。 個人的に気になるデータをいろいろ収集できて満足でした。

*1:いまはメモリも高いですし、壊したくないです。

モバイルノートPCは.NET開発に使えるのか

f:id:masatsuna:20210606055332p:plain

本シリーズのまとめはこちらにあります。

tsuna-can.hateblo.jp

前回まで、 CPU の差異や、コア数の差異による .NET Core アプリケーションのビルド時間を計測、検証してきました。 これまでの検証結果から、 CPU を最新世代の強いものに変えること、 8 Core 以上の CPU を用意することで、ビルド時間の短縮に大きな効果が得られることがわかっています。

tsuna-can.hateblo.jp

tsuna-can.hateblo.jp

tsuna-can.hateblo.jp

ここまでは、デスクトップ PC におけるビルド時間の検証を主に行ってきました。 しかし、最近はモバイルノート PC で開発を行う機会が増えてきていると思います。 一昔前とは異なり、モバイルノート PC の性能は大きく向上しており、開発作業ができなくはないレベルになってきていると、個人的には実感しています。 ただ、その実感というのが、デスクトップ PC と比較したときにどうなのか、という点は、私自身あまり検証したことがありませんでした。 今回は、第 10 世代の Intel モバイルノート向け CPU を搭載したノート PC (Surface Laptop 3)と、同世代のデスクトップマシンで、ビルド時間の比較を行ってみようと思います。

環境

今回検証に使用するマシンは以下の通りです。

項目 Surface Laptop 3 9th Core i7 構成 Zen3 Ryzen 構成
CPU Intel Core i7 1065G7 Intel Core i7 9700K AMD Ryzen 9 5900X(PBO は自動に設定)
メモリ LPDDR4x 16GB DDR4 8GB × 2枚(2666MHz) DDR4 32GB × 2枚(3200MHz)
記憶装置 256GB SSD 1TB NVMe M.2 SSD(PCIe 3.0) 1TB NVMe M.2 SSD(PCIe 4.0)
マザーボード - ASUS TUF Z390-PLUS GAMING MSI B550 TOMAHAWK
CPUクーラー - Nocture NH-U12A Nocture NH-D15

ちなみにこれらの CPU の Cinebench R23 におけるベンチマークを以下に貼っておきます。

項目 Intel Core i7 1065G7 Intel Core i7 9700K AMD Ryzen 9 5900X
Multi Core 4,475 9,214 21,878
Single Core 1,153 1,246 1,622

Core i7 1065G7 はモバイルノート PC 向けの省電力 CPU です。 TDP も 15W と圧倒的に少なく、性能面では、比較するまでもなく大きな隔たりがあります。 この CPU はデスクトップ CPU とどの程度戦えるのか、というのが今回のメインテーマとなります。

なお Surface Laptop 3 はすでに在庫限りとなっており、各社通販サイトでも、今回使用したモデルはもう購入できないようです。 別スペックの物は 2021/6/4 現在、まだ在庫があるようですね。


なお Surface Laptop シリーズは、第 11 世代の Intel モバイルノート向け CPU または Zen2 世代の Ryzen のモバイル向け CPU を積んだ新しいモデルが登場しています(Surface Laptop 4)。 今回検証で使用する PC は、世代としては 1 つ前の物ではありますが、まだまだ現役最強クラスの性能を持つモバイルノート PC の 1 つであると思います。


検証内容

検証は .NET 5 のアプリケーションをビルドし、ビルド時間を比較する方法で行います。 対象のソースコードは、 2021 年 5 月初旬に取得したものを使用します。 各アプリケーションは、 NuGet パッケージを参照しているため、事前にパッケージをすべてローカルにダウンロードした状態でビルドを行います。 ローカルファイル内にパッケージがあれば、ダウンロードする処理は行われないため、ネットワークの影響を限りなく無視することができます。

今回検証の対象となるアプリケーションは、以下の 2 つを利用します。

eShopOnWeb

github.com

こちらはマイクロソフト社が開発している .NET Core のリファレンスとなるアプリケーションです。 リファレンスとして使用するもので、プロジェクトの数も 9 つしかありません。

Entity Framework Core

github.com

.NET Core で使用できる代表的な O/R マッパーです。 こちらはそれなりに規模が大きく、 46 プロジェクトで構成されています。

検証手順

eShopOnWeb

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

dotnet restore eShopOnWeb.sln

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

dotnet build eShopOnWeb.sln

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 7 回ずつ実行します。

Entity Framework Core

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

restore.cmd

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

build.cmd

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 7 回ずつ実行します。

検証結果

eShopOnWeb のビルド時間

f:id:masatsuna:20210605173702p:plain

Entity Framework Core のビルド時間

f:id:masatsuna:20210605173713p:plain

結果を見てみましょう。 どちらの結果をみても、明らかに Surface Laptop 3 の Core i7 1065G7 の性能が悪いことがわかります。 eShopOnWeb の方は約 5.8 秒遅く、 Entity Framework Core の方に至っては約 39 秒も遅いです。

考察

モバイルノート PC 向けの CPU とデスクトップ PC 向けの CPU では、ほぼ同じような世代の中でも大きな差がつくことがわかりました。 正直な話、こうなることは、やる前からある程度想像がついていました。 CPU のベンチマークを見てみても、圧倒的な性能差があります。 また Core i7 1065G7 は、 4 コア 8 スレッドで、コア数もスレッド数も、デスクトップ PC 向けの CPU とは差があります。 要するに、勝てる要素は何ひとつないわけです。 そうであるなら、こういった結果になるのはある意味妥当であると考えられます。

ベンチマークの結果で見比べると、最新世代のモバイルノート PC 向け CPU は、私が以前使っていた Core i7 4790K とほとんど同じようなスコアです。 どちらも 4 コア 8 スレッドで、シングルスレッドの性能は Core i7 1065G7 のほうが少し上、マルチスレッドの性能は Core i7 4790K のほうが少し上、という感じです。 当時検証したものと全く同じコードではないため、今回の比較対象からは外していますが、おおよそ同程度の時間、ビルドにかかっています。 CPU のベンチマークというのは割といい線ついているんだなーというのがわかります。 以前の検証結果はこちらから確認できます。

tsuna-can.hateblo.jp

モバイルノート PC で大規模なプロジェクトの開発は無理がある

話を今回の比較に戻します。 この結果からわかることとして、大規模なプロジェクトの場合、モバイルノート PC で開発作業にあたることが無謀である、ということがわかります。 規模の大きなプロジェクトの場合、 Entity Framework Core のプロジェクトの数倍から数十倍の規模になることはよくあると言えます。 Visual Studio 2022 が 64bit 化されるとアナウンスされたとき、割と歓迎の声が聞こえていました。 これは、それだけ規模の大きなプロジェクトを扱っている人が多いということなのだと思います。 そういったプロジェクトに触れる機会が多いのであれば、モバイルノート PC では満足いく性能を得られない可能性が高いと言わざるを得ません。

モバイルノート PC のコストパフォーマンス

コストパフォーマンスの面でも、モバイルノート PC は、あまり優れたものではありません。 今回紹介している Surface Laptop 3 のマシンは、定価で税込み約 20 万円ほどでした。 これだけの金額があれば、デスクトップ PC は余裕で超ハイスペックなものを組めてしまいます。 プログラム開発用途であれば、グラフィックボードは「映ればよい」程度のもので問題ありません。 なんなら CPU 内臓の GPU でも全く問題ないと思います。 そう考えると、モバイルノート PC のコストパフォーマンスの悪さは一層際立ちます。 Core i7 11700K を使って、 32 GBメモリ、 1TB SSD(M.2)を前提で組むと、たぶんケースとかケチれば、15 万以内(OS 込み)で組めると思います。 ゲームをしないのであれば、ほとんどの人にとって過剰スペックなマシンで、この値段です。

モバイルノート PC の良いところ

モバイルノート PC の良さは、持ち運びできる軽さと、事務作業などの軽い作業を問題なくこなせる性能を両立しているところにあります。 デザイン面もよく、多くのものが洗練された素晴らしいデザインをしています*1。 要するに、持ち運んでちょっとした仕事をすることに特化した PC であって、 IT エンジニアがガンガン開発を行うことを想定したものではないのです。 もちろんちょっとした開発なら余裕でこなせますが、規模が大きくなると問題になることが、今回の検証でも明らかと言えます。 どの部分に価値を置くかは人それぞれだと思いますが、性能を求めるのであれば、モバイルノート PC を選択することはあまり良い選択とは言えません。

しかし、処理性能に対する消費電力という意味では、モバイルノート PC の能力は桁違いに高いと言えます。 今回使用した Core i7 1065G7 の TDP はわずか 15W です。 デスクトップ用の CPU は 65W~ であり、ワットパフォーマンスではモバイルノート PC の圧勝です。 7 ~ 8 年くらい前のデスクトップ PC を持ち運んでいる、という感覚でよいのかもしれません。

まとめ

今回はモバイルノート PC を .NET 開発で使えるのか、ビルド時間の側面から検証してみました。 プロジェクトの規模が小さいうちは、問題なく .NET 開発に利用できるものの、規模の大きなプロジェクトになると、モバイルノート PC の性能では力不足となる可能性が高いことを確認できました。

私の周りには、こういった無理な環境での開発を強いられている人を割と見かけます。 2 年ほど前見かけたとある開発現場では、この SSD 全盛の時代に、 HDD 搭載の激安ノート PC 使って開発していたんですよね。 当時 5 ~ 6 万くらいで購入できるレベルのものでした。 アプリケーションのビルドに 20 分以上かかっていて、本当にどうやって開発を進めているのか疑問でした。 コストをかけたくない経営側の気持ちはよくわかりますが、これでは余裕で足が出ますよね。 即刻 SSD 搭載の最新機種に切り替えさせましたが。。。

私自身も、こういう環境を経験してきた人の 1 人です。 社会人になってすぐ支給された PC は、起動するのに30分くらいかかる PC でした。 スペックもひどく、まともに開発作業なんてできませんでした*2。 それでも大量の開発をこなさなければならず、当時は本当につらかった記憶しかありません。

経営者やマネジメントの方々、 PC は IT エンジニアにとって最も重要な仕事道具です。 おもちゃのバットで打席に立つ野球選手がいないように、プロにはそれなりのものを与えるべきだと私は思います。 この検証結果をもとに、無理な開発を強いられている人が少しでも減ることを願っています。

次回はこのシリーズの最終回として、メモリの速度に焦点を当ててみようと思います。

*1:某コーヒーショップでドヤるためにはここが重要ですね。笑

*2:当時はノート PC 2 台準備して、 1 台は開発専用、もう 1 台はメーラーと設計書確認用、という人間系のマルチスレッド処理をしていましたね。そのくらい PC の性能が足りていませんでした。

.NET アプリケーションのビルドにはコア数は必要なのか

f:id:masatsuna:20210602200410p:plain

前回まで、 CPU の差異による .NET Core アプリケーションのビルド時間を計測、検証してきました。 ここまでの結果から、「 CPU を新しくハイパワーなものに変更することで、ビルド時間を大きく短縮することができる」ことが明らかになりました。 しかし、前回検証した Core i7 9700K と Ryzen 9 5900X の検証結果から、実は CPU のシングルスレッド性能より、コア数の差がビルド時間に影響を与えるのではないか、という仮説が生まれました。 今回はこの仮説がどの程度正しいのか検証していこうと思います。

環境

今回検証に使用するマシンは以下の通りです。

項目
CPU AMD Ryzen 9 5900X(PBO は有効に設定)
メモリ DDR4 32GB × 2枚(3200MHz)
記憶装置 1TB NVMe M.2 SSD(PCIe 4.0)
マザーボード MSI B550 TOMAHAWK
CPUクーラー Nocture NH-D15

この PC に Hyper-V をインストールし、 Windows 10 の仮想マシンを作成します。 作成するマシンには、 16GB のメモリを割り当てます。 CPU の仮想プロセッサ数を 4 個、 8 個、 12 個とします。

検証内容

検証は .NET 5 のアプリケーションをビルドし、ビルド時間を比較する方法で行います。 対象のソースコードは、 2021 年 5 月初旬に取得したものを使用します。 各アプリケーションは、 NuGet パッケージを参照しているため、事前にパッケージをすべてローカルにダウンロードした状態でビルドを行います。 ローカルファイル内にパッケージがあれば、ダウンロードする処理は行われないため、ネットワークの影響を限りなく無視することができます。

今回検証の対象となるアプリケーションは、以下の 2 つを利用します。

eShopOnWeb

github.com

こちらはマイクロソフト社が開発している .NET Core のリファレンスとなるアプリケーションです。 リファレンスとして使用するもので、プロジェクトの数も 9 つしかありません。

Entity Framework Core

github.com

.NET Core で使用できる代表的な O/R マッパーです。 こちらはそれなりに規模が大きく、 46 プロジェクトで構成されています。

検証手順

eShopOnWeb

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

dotnet restore eShopOnWeb.sln

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

dotnet build eShopOnWeb.sln

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 7 回ずつ実行します。

Entity Framework Core

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

restore.cmd

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

build.cmd

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 7 回ずつ実行します。

検証結果

eShopOnWeb のビルド時間

f:id:masatsuna:20210524204157p:plain

Entity Framework Core のビルド時間

f:id:masatsuna:20210524204208p:plain

結果を見てみましょう。 まずどちらの結果を見ても、プロセッサ数が 4 個の場合、明らかにパフォーマンス劣化が起きています。 プロセッサ数が 8 個以上ある場合、規模が小さいうちはそれほど大きな差はありませんでした。

しかし、規模が大きいプロジェクトでは、プロセッサ数 12 個と 8 個で平均で約 2.5 秒の差がついています。

考察

やはりプロセッサ数が少ないと、ビルド時間に多大な影響が出ることが明らかです。 eShopOnWeb のプロジェクトは、かなり規模の小さなものであると思います。 それであっても、プロセッサ数が 4 個になると性能差が明らかにわかるようになります。 率にすると 5% 程度の差があるようです。

規模が大きくなると、さらにその差は顕著についていきます。 Entity Framework Core のビルド時間は、 4 Core と 8 Core で約 12 秒の差がついています。 率にすると、 27% 程の差がついていることになります。

12 Core まで増やすと、規模の小さなプロジェクトではほとんどビルド時間に差が出なくなっていきます。 規模の大きなプロジェクトでも 6% 程度の差に収まっています。

以上の結果から考えると、最低限プロセッサ数 8 個を確保したほうが、エンジニアとしては幸せになれるということでしょう。

Azure Pipelines のビルドエージェント

ここまでの話は、ビルドマシンとして使う場合にも当てはまります。 例えば Azure Pipelines で利用できる Microsoft Hosted のビルドエージェントは、 Azure の VM でいうところの Standard_DS2_v2*1 を利用しています。 Standard_DS2_v2 は、仮想プロセッサ数 2 つの VM で、ここまでの検証結果から考えると、かなり貧弱なマシンであると言えます。 規模が小さいうちはあまり問題にならないかもしれませんが、プロジェクト数が増えたり、規模が大きくなったりすると、なかなかしんどい結果になることが予想できます。

実際にそれなりに大きな規模のプロジェクトの場合、8 Core くらいの VM を Self Hosted Agent として準備すると、驚くほどビルド時間が短縮できます。 ビルド時間がローカルの開発マシンと比較して長くかかるような現象が見られたら、スケールアップしてコア数を増やすことで、ビルド時間を短縮できる可能性が高いことを示せたと思います。

ただし、 8 Core を超えるマシンを準備しても、ビルド速度という意味ではあまり大きな改善が見込めないかもしれません。 もちろんプロジェクトの構成によっては、並列ビルドが有効に働き、効果が発揮できる可能性も否定できません。 しかし、費用対効果という意味では、 8 Core に軍配が上がる可能性が高くなりそうです。

まとめ

今回は、コア数の差が.NET アプリケーションのビルド時間に影響を与えるかどうか検証してきました。 その結果、コア数はかなり重要な要素であり、コア数が増えた方がビルド時間を短縮できることがわかりました。 また .NET アプリケーションのビルドには、 8 Core くらいのマシンがコストパフォーマンスが良い、という結果が得られました。

今回もなかなか興味深い結果であったと思います。 そして、これまで言われてきた「プログラム開発にはシングルスレッド性能のほうが重要である」という定説は、現在の .NET アプリケーションの開発では、あまり当てはまらないことも確認できました。

ここまで数回にわたって、 .NET アプリケーションのビルドに関するパフォーマンス調査を行ってきました。 次回は、最近開発で利用することの増えてきたモバイルノート PC におけるビルド時間を、 Ryzen 9 5900X と比較してみようと思います。

*1:2021/5/31 現在

Core i7 9700K と Ryzen 9 5900X におけるビルド速度の比較

f:id:masatsuna:20210516194909p:plain

本シリーズのまとめはこちらにあります。

tsuna-can.hateblo.jp

前回は約 6 年前の PC と、現役世代のマシンとで、.NET Core のアプリケーションのビルド速度を比較してきました。 その結果、 PC の最新化によってかなりビルド速度が高速化できることがわかりました。

tsuna-can.hateblo.jp

今回は、比較的新しめの Intel 系 CPU と AMD 系 CPU の比較をしてみようと思います。 例によって CPU 以外にも異なる点が多々ある環境で比較しますので、 CPU の性能差以外にも影響を与えている可能性は十分に考えられます。 できる限り比較する PC のスペックを記載しますので、数値を見る際は、環境の差異にも注意してお読みいただければと思います。

環境

今回比較する 2 台のマシンは以下の通りです。 他にもいろいろ違う点はありますが、検証内容と関係ないものは記載を省いています。

項目 9th Core i7 構成 Zen3 Ryzen 構成
CPU Intel Core i7 9700K AMD Ryzen 9 5900X(PBO は有効に設定)
メモリ DDR4 8GB × 2枚(2666MHz) DDR4 32GB × 2枚(3200MHz)
記憶装置 1TB NVMe M.2 SSD(PCIe 3.0) 1TB NVMe M.2 SSD(PCIe 4.0)
マザーボード ASUS TUF Z390-PLUS GAMING MSI B550 TOMAHAWK
CPUクーラー Nocture NH-U12A Nocture NH-D15

ちなみにこれらの CPU の Cinebench R23 におけるベンチマークを以下に貼っておきます。

項目 Intel Core i7 9700K AMD Ryzen 9 5900X
Multi Core 9,214 21,878
Single Core 1,246 1,622

前回比較した Core i7 4790K から大幅にスペックアップしたCPU です。 Single Core のスコアが約 20 %、 Multi Core のスコアが 約 87 %向上しています。 Core i7 9700K は 8 コア 8 スレッド、 Ryzen 9 5900X は 12 コア 24 スレッドで、 Multi Core に大きな性能差があるのは仕方がない面もあります。 またSingle Core のスコアにも大きな差があります。 Core i7 9700K は 2018 年 4Q に発売、対する Ryzen 9 5900X は 2020年 4Q 発売と、 2 年ほど Ryzen 9 5900X のほうが新しい CPU です。



検証内容

検証は .NET 5 のアプリケーションをビルドし、ビルド時間を比較する方法で行います。 対象のソースコードは、 2021 年 5 月初旬に取得したものを使用します。 前回の記事とは異なる時期に取得したソースコードです。 各アプリケーションは、 NuGet パッケージを参照しているため、事前にパッケージをすべてローカルにダウンロードした状態でビルドを行います。 ローカルファイル内にパッケージがあれば、ダウンロードする処理は行われないため、ネットワークの影響を限りなく無視することができます。

今回検証の対象となるアプリケーションは、以下の 2 つを利用します。

eShopOnWeb

github.com

こちらはマイクロソフト社が開発している .NET Core のリファレンスとなるアプリケーションです。 リファレンスとして使用するもので、プロジェクトの数も 9 つしかありません。

Entity Framework Core

github.com

.NET Core で使用できる代表的な O/R マッパーです。 こちらはそれなりに規模が大きく、 46 プロジェクトで構成されています。

検証手順

eShopOnWeb

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

dotnet restore eShopOnWeb.sln

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

dotnet build eShopOnWeb.sln

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 7 回ずつ実行します。

Entity Framework Core

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

restore.cmd

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

build.cmd

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 7 回ずつ実行します。

検証結果

eShopOnWeb のビルド時間

f:id:masatsuna:20210510204755p:plain

Entity Framework Core のビルド時間

f:id:masatsuna:20210510204810p:plain

結果を見てみましょう。 プロジェクト数の少ない eShopOnWeb の方は、わずかに Ryzen 9 5900X のほうがビルド時間は短いものの、平均時間で 0.12 秒の差しかなく、ほとんど誤差レベルの差しかありません。 それに対して Entity Framework Core の方は、平均時間で約 9.4 秒の差が出ており、圧倒的に Ryzen 9 5900X のほうが早いと言えます。

考察

正直ここまではっきり差がつくとは思ってもいませんでした。 昔からプログラム開発やビルド作業には、シングルスレッドの処理性能が重要であると言われてきました。 しかし、このレベルまで進化した CPU *1では、ベンチマーク上の差はあっても、シングルスレッドの性能差がこれほど大きくビルドの実行時間に対して影響を与えるとは考えられません。

こう考察する理由に、ビルド実行時の CPU 使用率があります。 実はこれらのアプリケーションのビルドを行っているとき、 CPU 使用率はほとんどの時間で 100% になりません。 これはコア単位で見たときも同様で、すべてのコアがほとんどの時間、 70% ~ 90% で推移することが見て取れます。 100% になるのはほんの一瞬の時間しかありません。 シングルスレッドの処理性能が重要なのだとしたら、いくつかのコアが 100% に張り付くような現象が起こるはずです。 しかし、こういった現象は、どちらの CPU も一切確認できませんでした。 そう考えると、今の時代のビルド環境には、シングルスレッドの処理性能を追求することより、コアの数を増やす方が効果的であるという仮説が立てられそうです。

なお規模の小さい eShopOnWeb プロジェクトは、プロジェクト数が少なかったため、コア数の恩恵をあまり受けられなかったことで、時間にそれほど差がつかなかったと考えることができそうです。

まとめ

今回は Intel Core i7 9700K と AMD Ryzen 9 5900X のマシンで、.NET Core のアプリケーションをビルドする時間の比較と考察を行いました。 その結果、昨今のビルド作業では、 CPU のシングルスレッド性能を追求するより、コア数の多い CPU を選択したほうが幸せになれる可能性が高いことを確認しました。 なかなか興味深い結果になったと思います。

次回は、今回浮かび上がった「ビルドにはコア数を増やす方が効果的」という仮説を検証するため、 Ryzen 9 5900X の上に Hyper-V仮想マシンを立ち上げ、割り当てるコアの数を増減させてビルド時間を検証してみます。 果たしてどんな結果になるのか。。。

*1:例えばモバイル用 CPU とデスクトップ CPU など、用途や使われ方が全く異なるものを持ってくれば確実に差は出ると思いますが。

Core i7 4790K と Ryzen 9 5900X におけるビルド速度の比較

f:id:masatsuna:20210508172345p:plain

本シリーズのまとめはこちらにあります。

tsuna-can.hateblo.jp

皆さんが自作 PC を作る目的は何でしょうか。 多くの方が PC ゲームを快適に行うことか、動画作成や画像編集など、クリエイティブな作業を快適に行うことなのではないかと思います。 CPU や GPU の新製品が出ると、ベンチマークソフトやゲーム、動画作成の時間など、様々な検証が行われます。 しかし、 IT エンジニアにとって有益な情報はほとんど出てきません。 IT エンジニアとして知りたいのは、プログラム開発をどの CPU なら快適に行えるのか、ということなんです。 しかし、そういった情報は全くと言っていいほど出てきません(需要がないんでしょうけど)。

今回は今まであまり語られることのなかったプログラム開発の側面から、第 4 世代 Core i7 と、 Ryzen 9 5900X を比較してみようと思います。

環境

今回比較する 2 台のマシンは以下の通りです。 他にもいろいろ違う点はありますが、検証内容と関係ないものは記載を省いています。

項目 4th Core i7 構成 Zen3 Ryzen 構成
CPU Intel Core i7 4790K AMD Ryzen 9 5900X(PBO は有効に設定)
メモリ DDR3 4GB × 4枚 DDR4 32GB × 2枚(3200MHz)
記憶装置 80GB 2.5インチSATA SSD 1TB NVMe M.2 SSD(PCIe 4.0)
マザーボード ASUS MAXIMUS VII HERO MSI B550 TOMAHAWK
CPUクーラー 前マシンから使いまわしの巨大なトップフロー型クーラー(もはや型番とか記憶にない) Nocture NH-D15

ちなみにこれらの CPU の Cinebench R23 におけるベンチマークを以下に貼っておきます。

項目 Intel Core i7 4790K AMD Ryzen 9 5900X
Multi Core 4,936 21,878
Single Core 1,069 1,622

比較するのもアレですが、相当な性能差がある、ということを理解してください。 Core i7 4790K は 2014 年にリリースされた、当時はそれなりに強い CPU でした。 それに対して Ryzen 9 5900X は、 2020 年現在最強に近い性能を持つ CPU です。 どちらも同一世代内では最強に近い性能を持つ CPU です。

検証内容

検証は .NET 5 のアプリケーションをビルドし、ビルド時間を比較する方法で行います。 対象のソースコードは、 2020 年 12 月末に取得したものを使用します。 各アプリケーションは、 NuGet パッケージを参照しているため、事前にパッケージをすべてローカルにダウンロードした状態でビルドを行います。 ローカルファイル内にパッケージがあれば、ダウンロードする処理は行われないため、ネットワークの影響を無視することができます。

今回検証の対象となるアプリケーションは、以下の 2 つを利用します。

eShopOnWeb

github.com

こちらはマイクロソフト社が開発している .NET Core のリファレンスとなるアプリケーションです。 リファレンスとして使用するもので、プロジェクトの数も 9 つしかありません。

Entity Framework Core

github.com

.NET Core で使用できる代表的な O/R マッパーです。 こちらはそれなりに規模が大きく、 46 プロジェクトで構成されています。

検証手順

eShopOnWeb

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

dotnet restore eShopOnWeb.sln

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

dotnet build eShopOnWeb.sln

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 7 回ずつ実行します。

Entity Framework Core

上述のリポジトリからソースコード一式を取得します。 取得したディレクトリをカレントディレクトリに設定し、コマンドプロンプトから以下のコマンドを実行します。

restore.cmd

これで NuGet パッケージをローカルにダウンロードできます。 続いて、 CPU がアイドル状態になり、温度も一定になったことを確認してから、以下のコマンドを実行します。

build.cmd

実行すると、実行時間が最後に表示されるので、その時間を記録します。 この作業を各環境で 5 回ずつ実行します。

検証結果

eShopOnWeb のビルド時間

f:id:masatsuna:20210508164216p:plain

Entity Framework Core のビルド時間

f:id:masatsuna:20210508164237p:plain

結果を見ても明らかなとおり、 PC を最新のものに交換することで、かなりビルド時間の高速化ができたと言えます。 特に Entity Framework Core の方は、ビルド時間が半分以下まで短縮化されています。 ビルドを待っている時間は、 IT エンジニアにとって最もイライラする時間だと思います。 PC を最新化することで、そういった時間を削減することができるのです。

Cinebench R23 のスコアと比較すると、スコアが数倍になったからと言って、処理速度が数倍になる、ということではないことがわかります。 しかし、スコアが大きく上がっていれば、如実に実行時間として表れることは間違いなく言えそうです。

考察

ビルド時の PC のリソース消費を見ていると、ほとんどが CPU の処理時間でした。 ディスク IO など、 CPU とは異なる箇所がボトルネックになるかなーと想像していたのですが、 CPU のほうがボトルネックになるようです。 なお今回のマシンはメモリの速度も大きく異なるため、その性能差が結果に大きな影響を与えた可能性も考えられます。

今回検証したマシンは、世代も全く違いますし、メモリの速度も大幅に違います。 CPU の性能差だけで、これだけの差がついたと結論付けることはできません。 そのあたりは十分に注意して結果を見るようにしてください。

まとめ

これらの PC は、 2014 年と、 2020 年、それぞれの時点でそれなりのスペックを誇る PC であると思います。 6 年たってしまうと、相当に時代遅れなものになってしまうことが、改めて証明されたように思います。

今後同様の検証を何回かに分けて行おうと思います。 プログラム開発を行う上で、どういった環境がベストなのか、自分なりにいろいろ検証した結果をまとめていこうと思います。

パーツの紹介

今回の検証で使用した PC パーツは以下から購入可能です。






Ryzen CPU で Hyper-V を使う方法

f:id:masatsuna:20210215005450p:plain

Windows 環境で手軽に仮想マシンを使うのであれば、 Hyper-V を使うのが便利だと思います。 Windows に標準で搭載されているのが最大の利点ではないでしょうか。 検証作業とかで、ホストマシンの設定を汚したくないケースに結構活用できます。

今回は Ryzen CPU で Hyper-V を使うための手順を解説します。 Intel CPU の場合と設定する BIOS の項目が異なりますので注意しましょう。

環境

Hyper-V を有効にするためには、 Windows 10 Pro が必要です。 Home エディションでは有効にできないので注意しましょう。

なお BIOS は日本語に設定してあります。 英語版と微妙に違うところがあるかもしれませんが、適宜読み替えてください。

Windows の機能の有効化または無効化

Hyper-V を有効にするためには、 Windows 上で機能を有効に設定する必要があります。 [Windows の機能の有効化または無効化] を検索して実行しましょう。 そして [Hyper-V] の項目にチェックを入れれば有効化できます。

しかし、特に何も設定をせずに Hype-V を有効にしようとすると、 [Hyper-V] > [Hyper-V プラットフォーム] > [Hyper-V Hypervisor] のあたりに以下のようなメッセージが出ていることに気づきます。 f:id:masatsuna:20210214235605p:plain

このようなメッセージが出た場合は、 BIOS で設定を変更します。

BISO 設定を変更する

Hyper-V を有効にするには、 [SVM*1 Mode] を BIOS 上で有効にしなければなりません。 BIOS への入り方はマザーボードの種類によって異なります。 多くの場合は電源投入直後、 Windows の起動前に [Del] キー、 [F1] キー、 [F2] キーあたりを連打することで入れます。 B550 TOMAHAWK の場合(というか、たぶん MSIマザーボードの場合)は [Del] キー連打で入れます。 メーカー製のものはもっと凝った作りになっているケースもあるので、説明書をよく読みましょう。

BIOS に入ることができたら、 [SVM Mode] を有効にします。 MSIBIOS の場合は、以下の手順で有効にできます。

まずモードを [Advanced] に設定します。 [F7] キーを押下すると、 [EZ Mode] と [Advanced] を往来できます。

[OC] メニューを選択し、 [Advanced CPU Configuration] を選択します。 f:id:masatsuna:20210215002007j:plain

[SVM Mode] を選択します。 f:id:masatsuna:20210215002010j:plain

設定値を [無効(Disabled)] から [有効(Enabled)] に変更します。 f:id:masatsuna:20210215002015j:plain

設定が変更できたら [F10] を押下して設定を保存し、再起動しましょう。


再度 Windows の機能の有効化または無効化

設定が正しく実行できていると、 [Windows の機能の有効化または無効化] で Hyper-V の有効化ができるようになっています。 f:id:masatsuna:20210215002401p:plain

[Hyper-V] の項目にチェックを入れると、配下のすべての項目が有効化されます。 そのまま [OK] ボタンを押下して、機能を有効化しましょう。

少々待つと、以下のように再起動を促すダイアログが出ます。 f:id:masatsuna:20210215002815p:plain

再起動後に Hyper-V が利用できるようになります。

*1:Secure Virtual Machine

MSI マザーボードの BIOS を日本語化する

f:id:masatsuna:20210216013017p:plain

MSIBIOS は、日本語表記に対応しています。 メニューの項目は英語のままですが、各項目の説明文や、ちょっとしたところが日本語表記に書き換わります。 設定手順を示しておきます。

環境

  • Ryzen 9 5900X
  • B550 TOMAHAWK

BIOS に入る

まずは BIOS 画面に入ります。 BIOS への入り方はマザーボードの種類によって異なります。 多くの場合は電源投入直後、 Windows の起動前に [Del] キー、 [F1] キー、 [F2] キーあたりを連打することで入れます。 B550 TOMAHAWK の場合(というか、たぶん MSIマザーボードの場合)は [Del] キー連打で入れます。 メーカー製のものはもっと凝った作りになっているケースもあるので、説明書をよく読みましょう。


言語の設定を変更する

BIOS 画面右上の部分に注目してください。 [En] となっている個所をクリックします。

f:id:masatsuna:20210216011538p:plain

すると使用可能な言語の一覧が表示されるので、[日本語] を選択します。

f:id:masatsuna:20210216011614p:plain

うまく設定が終われば、右上の言語の設定箇所が [日] になります。 また左上の曜日表記が日本語に変化している様子も見られます。

f:id:masatsuna:20210216011655p:plain

正常に設定が変更できたら [F10] を押下して保存し、再起動しましょう。

PCをRyzen 9 5900Xで組んだ話(まとめ)

f:id:masatsuna:20210918011920p:plain

「PC を Ryzen 9 5900X で組んだ話」のシリーズ目次です。

第1回

更改前のメインマシン紹介と、 CPU 、ケースの選択について検討した経緯をまとめています。 tsuna-can.hateblo.jp

第2回

グラボの検討編です。正直値段だけで選びました。はい。 tsuna-can.hateblo.jp

第3回

チップセットの検討経緯をまとめています。 このあたりが今回の PC 自作にあたって一番悩みました。 tsuna-can.hateblo.jp

第4回

B550 チップセット搭載のマザーボードから、どうやって選定していったかまとめています。 B550 に限らず、一般的な検討手順なのではないかと思います。 tsuna-can.hateblo.jp

第5回

みんな大好き CPU クーラーと CPU グリスの選定経緯についてまとめています。 tsuna-can.hateblo.jp

第6回

メモリの選定経緯についてまとめています。 私の場合、大容量メモリが必要だったので、なかなか選択肢が広がりませんでしたが、選定手順には一般的な話を書いています。 tsuna-can.hateblo.jp

第7回

SSD の選定方法をまとめています。 tsuna-can.hateblo.jp

第8回

電源の選定方法と、最終的に作成した PC の構成をまとめています。 tsuna-can.hateblo.jp

性能比較

私の用途(プログラム開発)にあわせたベンチマークを取得しました。 新旧のデスクトップ向け CPU (Core i7 4790K 、 Core i7 9700K)、ノート PC 向け CPU (Core i7 1065G7)を使ってコンパイル速度の実測値を比較しています。 tsuna-can.hateblo.jp

tsuna-can.hateblo.jp

tsuna-can.hateblo.jp

PCをRyzen 9 5900Xで組んだ話(電源の選択編)

f:id:masatsuna:20210212011236p:plain

本シリーズのまとめはこちらにあります。

tsuna-can.hateblo.jp

今回で自作 PC のパーツ選定シリーズ最終回となります。 最後に電源ユニットの選択についてさらっと触れていきます。

前回の記事はこちらからどうぞ。

tsuna-can.hateblo.jp

消費電力を見積もる

電源を決めるうえで、最初に行わなければならないのは PC 全体の消費電力を見積もることだと思います。 ここまででパーツ構成が決まっているので、以下のようなツールを用いて、消費電力を見積もりましょう。

PC電源容量計算【2021年最新版】 | BTOパソコンミニ館

電源容量計算(電源電卓)電源の選び方|ドスパラ通販【公式】

そうすると、自分の PC の消費電力の推定値を計算することができます。 私の場合、合計使用量は最大で 450 W 程度であることがわかりました。

電源容量を見積もる

上記のサイトでは、電源容量の推奨値まで勝手に出してくれるのですが、これらのサイトはちょっと大きな値を出しすぎているように思います。 電源容量は、消費電力の 2 倍と計算するのが割と一般的かと思います。 私の場合は 900W ということになります、 しかし、それではさすがに多すぎます。 常時 100% の負荷を PC にかけ続けるわけではありません。 あまりにも大きな容量の電源を選んでしまうと、一番変換効率の良いゾーンを長く使うことができなくなってしまいます。 であるならば、最大の負荷がかかるような使い方をしたときは、変換効率の悪いゾーンで落ちない程度に働いていただいて、普段使いするときになるべくよい変換効率を得られるようにする、というのが基本戦略になります。

もう少しパーツ個別の消費電力に着目すると、いろいろわかることがあると思います。 例えば今回利用する Ryzen 9 5900X ですが、 TDP は 105 W と言いながら、ブーストがかかると 140 W くらいまで消費電力が上がるようです。 GPU についても同様に調べると、 RTX 3070 の最大消費電力は 220 W 程度、 OC している場合は 250 W 程度、となるようです。 最大負荷状態で動かしたとしても、 500 W まで消費することはなさそう、ということがわかります。 多少余裕を持ったとしても、 750 W あれば十分足りると考えました。 また 750 W にしておけば、あまり負荷のかかっていない状況でも、効率のよいゾーンで使ってくれそうです。

それなりに高性能な GPU を搭載しているのであれば、 PC 内で最も電力を食うのは GPU です。 GPU を選ぶ際、どの程度の電源が必要か、という情報が公開されているものもあります。 上記の見積もりをしたうえで、 GPU の仕様書も確認してみると、その確からしさを補強できると思います。

電源のサイズを決める

電源も物理的なサイズに差があります。 購入した PC ケースの仕様をよく読み、適したサイズの電源にまずは絞り込みます。 私は Fractal Design の Define 7 を購入しましたので、 ATX サイズの電源を使用することにしました。

ATX サイズの電源は品ぞろえの幅が最も広いという特徴があります。 ケースが許すのであれば ATX から選ぶことをお勧めします。

電源の SATA ポート、 PCIe ポートの数を確認する

特に電源容量の小さなモデルでは、使用可能な SATA や PCIe の電源ポート数が少なく設定されているため、自分の使いたい機器がすべて接続できるか確認しましょう。

プラグイン対応か否か

安い電源の場合、電源から各種ケーブルが直接はえているものが多いです。 こういった形状の場合、不要なケーブルが PC ケース内で邪魔になるという問題が起きます。 ケース内をすっきりさせたいならプラグイン対応のものをえらぶと良いと思います。

逆にプラグイン対応の電源の場合、差込口の接触が悪くなりがちです。 どちらにも一長一短ありますので、好きなほうを選べばよいとおもいます。

80PLUS 認証の確認

ここまで絞り込んでくると、それなりに商品数を絞り込むことができると思います。 あとは電源の性能を表す認証と価格のバランスを見て、実際に使用する製品を決めればよいと思います。 認証については、大体の場合製品の価格と比例して決まります。 予算と相談しながら決めてしまって問題ないと思います。

なお私はいつも 80Plus Gold の認証を得ているものから選択しています。 80Plus Silver 以下のモデルは確かに安いのですが、数がそれほど多くありません。 逆に 80Plus Platinum 以上のモデルになると、価格が急上昇してしまい、コスパの悪さが目立ちます。 最近の電源の多くが 80Plus Gold を取得していることからも、このあたりがメインストリームとして見られていると思います。

選択肢

私の今回の用途にあう電源として、いくつかよさそうなものを見繕いました。



電源に関しては、あまり冒険したくない思いがありました。 過去に使ったことがあって、各種レビューでの評判も悪くない有名どころを使うつもりで、上記 2 つを対象に考えていました。 そして PC ショップに行ったら、偶然 RM750x が特価で出ていたので、そちらを採用することにしました。

全体のまとめ

ここまで長々と、今回の PC を構築するにあたって、どうやってパーツを選んでいったのか、といったあたりを書いてきました。 最終的に私の構築した PC はこんな構成になりました。

項目 構成
CPU AMD Ryzen 9 5900X
メモリ Corsair Vengeance DDR4 3200MHz 32GB × 2枚
記憶装置(メイン) Samsung 980 PRO 1TB PCIe Gen 4.0
記憶装置(データ領域1) Seagate FireCuda 510 1TB PCIe Gen 3.0
記憶装置(データ領域2) ※ CFD 販売 SATA 2.5インチ SSD 900GB
記憶装置(データ領域3) ※ Crucial CT500MX200 SATA 2.5インチ SSD 500GB
記憶装置(データ領域4) ※ 東芝 MD04ACA200 SATA 3.5インチ HDD 2TB
マザーボード MSI B550 TOMAHAWK
グラフィックボード ASUS DUAL-RTX3070-O8G
CPUクーラー Nocture NH-D15
電源 Corsair RM750x
DVDドライブ ※ LG 製(型番不明)
ケース Fractal Design Define 7

※:前マシンから流用したもの

ここ最近の残業代を突っ込んだ結果、相当に満足いく構成で組み上げることができたと思います。 これからたくさん使いこんでいきたいと思います。

また後日、ベンチマーク結果についても書いていこうと思います。 パーツ選定の話は今回で終了です。

PCをRyzen 9 5900Xで組んだ話(SSDの選択編)

f:id:masatsuna:20210210003353p:plain

本シリーズのまとめはこちらにあります。

tsuna-can.hateblo.jp

前回はメモリの選定について書きました。 今回は SSD について書いていこうと思います。

前回の記事はこちらからどうぞ。

tsuna-can.hateblo.jp

SSD の種類

現在発売されている SSD には、その接続方式として NVMe 接続と、 SATA 接続の 2 種類があります。 マザーボードとの接続方法も、 M.2 スロットに接続する方法と、 SATA のポートに接続する方法の 2 種類があります。 M.2 スロットに接続する場合は、 NVMe 接続と SATA 接続どちらかで接続することになりますが、 SATA のポートに接続する場合は SATA 接続しか使えません。 また M.2 スロットは、必ず NVMe 接続、 SATA 接続、どちらもできるかというとそういうわけでもなく、マザーボードの仕様によってどういう接続方式が使えるかが決まっています*1

さらにややこしいのは、 M.2 スロットに NVMe 接続で接続する場合、 PCIe 3.0 なのか、 PCIe 4.0 なのか、でも差があります。 PCIe 4.0 のほうが新しい規格で、速度も PCIe 3.0 の 2 倍くらい高速です。 どういった SSD が接続できるかはマザーボードの仕様をよく確認しておきましょう。

私の購入した B550 TOMAHAWK は、 M.2 スロットが 2 本装備してあります。 そのうち 1 本は NVMe 接続 PCIe 4.0 / SATA 接続の両対応、もうひとつは NVMe 接続 PCIe 3.0 のみ対応です。 今回のマシンは、 M.2 スロットをフル活用していくつもりでしたので、あまりケチらず十分なスペックのものを選ぶことにしていました。

SSD にも互換リストがある

マザーボードメーカーが公開しているのか調べたことはありませんが、少なくとも MSI はストレージの互換性リストを公開していました。 心配性な私は、メモリと同じようにこの互換性リストの中から製品選定をすることにしました。 互換性リストは以下のページから参照できます。

https://jp.msi.com/Motherboard/support/MAG-B550-TOMAHAWK

メインストレージ(システムドライブ用)の選定

メインストレージに使う SSD は、できる限り高速なものを選んでおいた方が、 OS の起動速度、各種アプリケーションの起動速度を大きく向上してくれます。 そういったこともあり、メインストレージには NVMe 接続 PCIe 4.0 の M.2 スロットを使うことにしました。 速度重視なので、 PCIe 4.0 対応の SSD から選定することにしました。

容量は今使っている PC のストレージ使用量から、 1 TB に決めました。 512 GB でも間に合いそうだったんですが、 SSD なので容量は余裕を持っておいた方が良いかなーという雑な決め方です。 この条件で互換性リストを検索してみると、 8 件まで絞り込むことができました。 あとはメモリの時と同様、型番を価格.comで検索して、日本で入手できそうなものを探します。

最終的に選んだのは超ド定番のこちらの一品でした。


価格はそれなりにしますが、性能に全振りするとやはりこれになるかな、という感想です。

仮想マシンのイメージを保存するストレージの選定

続いて決めたのは仮想マシンのイメージを保存するストレージです。 今までは SATA 接続の 2.5 インチ SSD に格納していたのですが、複数台の仮想マシンを立ち上げるとディスク I/O が明らかにボトルネックになっている様子が見えていました。 そんなこともあり、今回はもうひとつの M.2 スロットを活用してやろうと思いました。

仮想マシンイメージを保存するため、ディスクアクセスの速度がそれなりに欲しいのと、耐久性が高いことが必須の要件となりました。 PCIe 3.0 接続の SSDMSI の互換性リストから抽出し、それらのディスクアクセス速度や、 TBW をもとに絞り込みました。

正直 TBW の値は「参考値」扱いだと思います。 公式に TBW の値を公開していないものは怪しいかもしれません。 しかし、 TBW の値は計測方法がそろっていないと比較できない値なので、 TBW の値だけを見て優劣を決められるようなものではないのかな、と思います。

最終的に選定したストレージはこちらです。


正直どこのものでもよかったのですが、高耐久であることをアピールしていることと、 PCIe 3.0 の性能をしっかり出せていることが選定ポイントになりました。 また B550 TOMAHAWK には、 PCIe 3.0 の M.2 スロットにもヒートシンクが付属しています。 そのため、ヒートシンクの付属しないモデルを選択しました。 あと今まで SeagateSSD を使ったことがなかったので、どんなものか試してみたかった、という好奇心も選定に影響を与えたことは否めません。

今回はここまでです。 次回は電源の選定についてまとめて、このシリーズを締めたいと思います。

*1:とはいえ、これから新しくパーツをそろえるのであれば、 M.2 スロットに SATA 接続するケースはほとんどないと思いますが。

PCをRyzen 9 5900Xで組んだ話(メモリの選択編)

f:id:masatsuna:20210209005304p:plain

本シリーズのまとめはこちらにあります。

tsuna-can.hateblo.jp

前回まででマザーボードと CPU クーラーが決まりました。 今回はそれらに引きずられて決まるメモリについて書こうと思います。

前回の記事はこちらからどうぞ。

tsuna-can.hateblo.jp

容量を決める

メモリの選定にあたって、まず決めなければならないのは容量です。 昨今のブラウザーや各種チャットツールなど、普段使いするアプリケーションも、昔と比べてメモリをバカ食いする仕様のものが増えてきているように思います。 Windows も 64 bit が基本になっていますし、メモリバカ食いの時代はこれからも続くんだろうな、と思います。 なので、大した使い方をしていないのに、メモリが結構ひっ迫しているケースを最近よく見るように思います。

私が少し前まで会社で使っていた PC は、メモリ 8 GB のマシンでした。 Office とかブラウザーとかウィルス対策ソフトとか、常時使うアプリケーションをザーッと起動するだけで、半分くらいメモリを奪われていました。 そこに Visual Studio とか立ち上げようものなら、メモリ使用率 90% 超えが当たり前で、動作ももっさり、という状況でした。 いろいろなところに掛け合って、メモリ 16 GB のマシンをゲットしてから、メモリ不足に陥る問題は解消されました。 それでも常時 10 GB 以上使っているのが普通な感じです。 こんな状況だったので、最低でもメモリは 16 GB 以上必要だろう、と思っていました。

私は自宅のマシンで Hyper-V を多用します。 多い時だと 3 台の仮想マシンを使って、いろいろ勉強したり検証したりしています。 そうなると、ホストマシンが動作するように 16 GB、 3 台の仮想マシンそれぞれに 16 GB 割り当てる、と考えると、合計 64 GB あればよさそうだ、となりました。 Hyper-V には動的メモリ割り当てというメモリ節約のための機能があるにはあるのですが、最低容量を小さくすると処理遅延がひどくて使い物になりません*1。 そうであるなら、初めから 64 GB 用意しておけばいいじゃないか、と思ったわけです。

ほしい容量がわかったら、念のためマザーボードや CPU の仕様も確認しておきましょう。 私の選択した B550 TOMAHAWK ですが、仕様書を確認すると、最大メモリ搭載量は 128 GB となっています。 また Ryzen 9 5900X には最大メモリ容量の仕様について記載がないため、マザーボードの仕様に従うものと思います。 Intel 製 CPU の場合、 CPU にも最大メモリ容量が定められているので、自分の載せたい量が載るか、確認しておきましょう。


動画編集や画像編集のように、メモリを大量消費するアプリケーションを使う場合は、 1 台 16 GB では足りないと思います。 この辺は自分のマシンの使い方を観察して、適した容量を見積もりましょう。 PC パーツはほとんどのケースで「大は小を兼ねる」ので、予算に余裕があるなら多めに積んでおくことを個人的にお勧めします。

メモリの枚数を決める

私の選択した B550 TOMAHAWK には、メモリスロットが 4 スロット搭載されています。 64 GB のメモリを搭載するとして、メモリの載せ方には以下の 2 つの選択肢があります。

  • 16 GB のメモリを 4 本
  • 32 GB のメモリを 2 本

Ryzen CPU で組むのであれば、メモリの本数は 2 本を基本線にした方が良いと思います。 Ryzen CPU はメモリの本数を増やすと、メモリの動作クロックを下げなければなりません。 もちろんオーバークロックさせて動かすこともできるでしょうが、安定性は 2 本のほうが上になります。 逆に 1 本にしてしまうと、それはそれで性能低下を招くので、原則 2 本で考えておけばよいと思います。

メモリの動作クロックを考える

ここまでで 32 GB × 2 本という構成が決まりました。 次に決めるのは、このメモリの動作クロックです。 Ryzen CPU の場合、メモリの動作クロックを高めることで、それなりの性能向上が見込めます。 であるならば、製品保証の範囲内で、できる限り高速なものを選択したい、と考えました。

Ryzen Zen3 CPUの場合、メモリを 2 枚さしたときは DDR4-3200 で動作します。 これを超えた場合はオーバークロック扱いになります。 私は原則オーバークロックせずに使いたかったので、 DDR4-3200 をターゲットとすることにしました。

マザーボードのメモリ対応表を確認する

あとは好きなメモリを選べばよいのですが、安心安全なメモリを選びたいなら、マザーボードメーカーの出している対応メモリリストを確認してみましょう。 B550 TOMAHAWK の場合は、 MSI のサポートページに対応メモリの一覧が掲載されています。

2020/02/06 現在の確認方法を書いておきます。 まずは以下のページに行きましょう。

https://jp.msi.com/Motherboard/support/MAG-B550-TOMAHAWK

左側のメニューで [互換性] を選択します。

f:id:masatsuna:20210206105133p:plain

上部のメニューから [Memory By RX-5xxx] を選択します*2

f:id:masatsuna:20210206105230p:plain

すると、マザーボードの対応しているメモリの一覧が表示されます。

f:id:masatsuna:20210206105443p:plain

このメモリリストの中から、先ほど決めた要件にあうメモリを探しましょう。 とんでもない量が掲載されているので、 Excel とかを使ってうまいことフィルタリングすることをお勧めします。

さて、私の場合は 32 GB × 2、 DDR4-3200 が要件ですので、これにあうものを実際に探してみます。 [Size] の列には 1 枚あたりのメモリ容量が載っているので、ここが [32GB] となっているものに絞り込みます。

続いてクロックでも絞り込みます。 [SPD Speed] の列にはメモリをさしたとき、デフォルトで適用されるクロックが書いてあります。 どうせ後で設定変更するので、この値の大小はあまり気にしなくてよいと思います。 絞り込みが必要なのは [RAM Speed] と [Supported Speeed] です。 今回は DDR4-3200 で動かしたいので、ここに書かれているクロックが 3200 MHz 以上になっているものを抽出します。 2020/02/06 現在、ここまでやると 32 個まで絞り込めました。

ここからは機械的にできない作業になってしまいます。 今回は 2 枚組、合計 64 GB のメモリが欲しいので、型番を眺めて明らかに違いそうなものを除外します。 例えば Hyper-X のメモリは、以下のようなものが見つかります。

  • HX432C16FB3/32
  • HX432C16FB3K2/64
  • HX432C16FB3K4/128

末尾の数字に注目すると、それぞれ上から順に 1 枚組、 2 枚組、 4 枚組であることがわかります。 他のメーカーでも、型番にメモリの総容量を含めているものが結構あるので、自分の欲しい枚数のものだけに型番からある程度絞り込んでしまいましょう。 型番からは想像できないものは、無理に絞り込まなくてよいと思います。 2020/02/06 現在、この作業を行うと 17 個まで絞り込めました。

CPU クーラー、 PC ケースからメモリの最大高を計算する

近年のメモリは、ヒートシンクがついていたり、 RGB でピカピカしたり、いろいろと付属物がくっついているものがあると思います。 こういったメモリは高さが結構あります。 大きめの CPU クーラーを使う場合は、メモリの上空に CPU クーラーのファン部分が張り出してきます。 そうなると、大型のメモリでは CPU クーラーのファンと干渉してしまうことがあります。

今回私が導入する Nocture の NH-D15 の場合、公式サイトにメモリのサイズに関する記載があります。

noctua.at

上記のページ内を参照すると、 CPU クーラーの高さ 165 mm に収めたいのであれば、メモリの高さは 32 mm 以内に収めなければなりません。 もちろんこれより高さのあるメモリを使うこともできますが、その分ファンを上方向にずらして取り付けなければなりません。 そうすると、 CPU ファンの高さが仕様書よりも高くなってしまいます。

PC ケースに記載のある CPU クーラーの最大の高さから、搭載可能なメモリの高さをまずは求めましょう。 FlactalDesign Define 7 は、 CPUクーラーの高さ 185 mm まで搭載可能となっています。 多少余裕をもって 180 mm までに収めて、メモリと CPU ファンの間にも 3 mm 程度の余裕を持たせようとすると、メモリの最大高はこのようになります。

32 mm + ( 180 mm - 165 mm - 3 mm) = 44 mm

国内流通品の確認とメモリの高さの確認

次に確認するのは日本国内で入手できるかどうかです。 これは型番で価格.com を検索すれば、入手可能かどうかある程度判断できます。 PC パーツを扱っているショップはほとんど価格.com と連携しているので、ここで型番を検索して出てこなければ、日本で入手できないと判断してしまってよいと思います。

入手できそうなものについては、メモリの高さを確認しておきましょう。 今回はパソコンショップ Ark の通販サイトが一番調査に役立ちました。 公式サイトに記載のないメモリの高さの情報が載っているので本当にありがたいです。

www.ark-pc.co.jp

リストアップしたものの中から、高さが 44 mm 以内のもので絞り込みます。 2021/02/06 現在、 3 件まで絞り込みができました。

製品選定

適合するものの中から、価格とスペックを見比べて製品を決めていきましょう。 最終候補に残ったのは以下の 3 点でした。



kakaku.com

キングストンのメモリは Amazon では完売しているようです。

私の場合、メモリは DDR4-3200 をターゲットにしていたので、 3600 MHz 動作のメモリは過剰スペックでした。 当然選別品でしょうから、同型の Corsair のモデルより 8,000 円近く高かったです。

Corsair とキングストンのメモリでは、性能差はほとんどないのに、キングストンのメモリのほうが約 7,000 円高かったです。 そんなこともあり、最終的には超定番の「CMK64GX4M2C3200C16」を採用することとしました。

今回はここまでです。 次回は SSD の選定について書きたいと思います。

*1:たぶん一時的に大容量のメモリを割り当てる用途だと思います。メモリサイズを極端に小さく保つためのものではない印象です。

*2:たぶん「RX-5xxx」は「Ryzen 5###X」という意味なんだと思う。