ここ最近、仕事での動画編集の割合がガバッと増えてきて、割とどうしようかずっと悩んでいたメインメモリ。ショップに行ってはメモリ価格のチェックをしまくって、とりあえずなんとかしたいとずーっとずーっと悩んでいたのですが、ある日気を失って気づいたら手に！　というお約束すぎるお約束の結果、あろうことかメモリ容量が4倍、第1世代ThreadRipperでは最大容量となる128GBになりました。

通常使用時はオーバースペック、重量級作業時は「あればあるだけ食う」という不条理

そもそも論なのですが、ごく一般的にWindows10環境でPCを使う際、128GBなんて容量は全く全然これっぽっちも必要ないくらいにはオーバースペックな数字です。なんなら32GBでも多すぎるくらい。実際、普通にPCを使っていたり、ゲームやってそれを録画したり、みたいな使用用途であれば、16GBもあれば充分、まぁ余裕を見て32GBくらいかな、程度の使用量で、その点に関しては増設した現状でもさほど変わりありません。強いて言うならば、最近のソフトウェアはWindowsそのものも含めて、「搭載しているメモリ総容量を見て、実際の使用量（予備的な先読み領域も含む）を決定する」という挙動をするものが非常に多く、有名所ではブラウザのGoogleChromeが「アホほどメモリ食う」というアレ。4GB環境、8GB環境、16GB環境、32GB環境、そして今回の128GB環境と数パターンの環境でメモリ使用率のチェックを何度も行ってきましたが、基本的に「搭載メモリ量が少なければ使用率も落とす、搭載量が多ければ使用率を上げる」という挙動をしており、Windows10の64bit環境であっても、メモリ4GBのタブレットで、性能に見合った程度の作業（せいぜい動画見たり、テキスト打ちやったり）であれば、それほど困ったことにはなりません。

（ハイクロックメモリでも2枚1セットがメジャーに）

一方で、先述した動画編集等を含む「相応に重量級の作業を行う」際には、これが逆転します。映像編集では主にAfterEffectsを使用しているのですが、内部的な設定で「使用メモリ量の上限」を設定する画面があり、ここで手打ちで使用率を決めてあげれば、その分で動作をしてくれはするのですが、32GB環境で上限16GB程度に打った際、「動画データの無い、テキストのみのトランジション系プロジェクト」を開いた時点でほぼ頭打ちまで領域確保を行ってきます。ここからさらにプレビュー等で仮エンコードを行わせる状態になると、設定した上限値を超えてしまう為に、ストレージ（SSDだのHDDだの）にデータを置きながらエンコードを行ってプレビューを表示させる、という動作をしているようでした。使用しているPCのメインストレージはM.2のNVMe SSDなので、たしかに速度という点では気にするほどでも無いのですが、原則的に小容量のシステムドライブとして、テンポラリデータを置く想定が無い為、作業中にストレージ不足の警告を出すことも。ここにさらに「素材用の動画データ」を追加すると、完全に設定したメモリ領域が枯渇する為、いよいよストレージへの負担が大きくなります。5分にも満たない動画データ（FHD解像度の60fps）で制作を行った時でもその傾向は顕著で、ストレージ側のテンポラリデータを確認すると、仮エンコード（プレビュー用に解像度等を落としたエンコード）の状態であっても20GBを超えるサイズで配置されていました。この辺の数字は制作動画や使用データ類、各種設定等で大きく変わる点なので一概には言えないのですが、それにしてもテンポラリとして20GBも吐き出される状態というのは（SSDにも、ユーザ自身にも）健康上よろしくない状態の為、さすがになんとかしたかった、というのが今回の経緯。

（AfterEffects内のメモリ使用率設定。画面は増設後、96GBまで許容の設定）

そもそもPCの使用用途がワークステーション的な立ち位置（前回紹介記事）である事や、これまたCPUがThreadRipperという「とても一般的とは言えない」環境だったワケなのですが、設定編で記したように、「全体のバランス」が整っていないと、どれだけ強烈なCPUを積んでいようが必ずどこかでコケる、というもので、今回はそれがメモリだった、という結論に至ったわけです。ThreadRipper環境ではメモリコントローラがクアッドチャネルに対応しており、4本のスロットに対して同時にアクセス可能となっており、いわゆる「一般的」なAM4系、あるいはIntelのCore i系のような「M/B上のメモリスロットが最大4本」という環境の「デュアルチャネル」の倍にあたるので、元々の8GBモジュール*4本という環境でも、同時アクセスに関する速度については問答無用で上を行っていました。この辺はRAIDなんかでも似たようなもので、「メモリバスやメモリクロックが多少低速でも、同時に複数へアクセスして処理する事で速度を上げる」という分散処理を行うことで速度を補う方式で、それ自体は決して新しいものでも特殊なものでもなくなっています。現状メモリモジュールを購入しようとした際、「ほとんどが2本1セットで販売されている」というのもコレが理由。「1本で16GB」よりも「8GBモジュールを2本挿して計16GB」にしたほうが、理論上では同じ容量でもアクセス速度が変わり、結果として処理速度の向上に繋がります。尚、AMDのEPYCシリーズやThreadRipperの一部（※）、及びIntelのXeon等の「サーバ向けCPU」やその付随環境に関しては、これがさらに拡張されて「オクタチャネル（8チャネル）」対応となっている環境が多く、これも同様に「メモリバス8本に対して同時アクセスを行う」というもの。クライアントやワークステーションに比較してサーバ環境ではメモリアクセスの速度はかなり重要になる場面も多く、同時にメモリ1本あたりのコストを下げる事が可能にもなる「ハイクロックメモリで速度を稼ぐのではなく、同時アクセス数で速度を稼ぐ」というニーズに応えたものになっています。
（※本来ThreadRipperシリーズは全てクアッドチャネル対応が上限でしたが、「ThreadRipper Pro」という名称で第3世代からフォークされたシリーズがあり、こちらでオクタチャネルに対応しています。OC非対応（ブーストはアリ）の他、チップセットも変更されている為、これこそ完全に「ワークステーション向け」のCPUという立ち位置になります。「無印」と「EPYC」の中間に位置するシリーズです）

使用中のCPUに合わせた製品選択、メモリクロックは「そもそも伸ばしきれない」

例によって例のごとく、「AMDのZen系CPUはハイクロックメモリと組み合わせると性能を引き出せる」と言われるアレですが、実際の所は「モジュール数が少なく、かつモジュール上のチップ搭載枚数が少ない場合」という米印がついたりする部分があり、メモリ設定周りでクロックを盛って絶対的な速度を出そうとすると、以下のような条件がつきます。

・デュアルチャネルなら2枚、クアッドチャネルなら4枚で動かす
・チップ片面実装（SingleRank）の製品を選択する
・同一容量、同一クロックの製品、場合によって同一ロットのチップを使用
・使用しているCPU世代の最大メモリ速度を基準にモジュールを選択

最近だと4000MHzなんていうとんでもないクロックで動くOCメモリも出ており、かつ単発16GBや32GBのモジュールもあったりはするのですが、上述した通り、デュアルチャネルなら2本、クアッドチャネルなら4本までしか「同時アクセス」は行なえません。AM4系は一般的に4スロット、TR系は同8スロットのメモリスロットがありますが、それぞれ「A-1/B-1・A-2/B-2」といったスロット番号が打たれており（TR系ではさらに「C-1/D-1・C-2/D-2」）、M/Bメーカーによって番手が変わっていたりはするものの、基本的に（例えば）「A-1とB-1」に挿してあげない限り、デュアルチャネルでの同時アクセスは行われません。4本のメモリスロットを持つM/Bの大半では、スロットを一本飛ばしにしてモジュールを挿してあげるようなイメージ、というより実際にそのような環境が大半になるかと思います。TR系のクアッドチャネルの場合にも同様で、CPUを挟んで双方に2本ずつ、一本飛ばしで装着する事になります。私が現在使用中のM/BとなるASUSの「ROG STRIX X399-E GAMING」の場合、CPUを挟んで左右のモジュールスロットが上下逆になっており、今までの8GB4枚使用時には双方とも「一番外側に装着、一本飛ばして内側に装着、一番内側もブランク」という、左右対称の装着方法になります。メモリスロットが左右で逆転している事自体も含め、この点は他メーカー製M/Bでも同様だろうとは思います。この点はマニュアルにも明記されています。

（ASUS ROG STRIX X399-E GAMING マニュアルより抜粋）

RAID等も同様ですが、このように「マルチチャネルアクセス」を行う部分になると、「どのスロットが同時アクセスの対象になるか」という確認と適切な接続・装着が重要になります。尚、上図でいう「各2番」のスロットに挿してあるモジュールは「各1番」が溢れた時に使用される「セカンダリスロット」の扱いになる様子。この点も含め、次の内容になる「メモリクロック等を揃える」という点が重要になってきます。

さて、本題のメモリクロックに関してですが、基本的にはどんなハイクロックメモリであっても、積むことは出来るし、動作もするでしょう。最近ではM/Bメーカーだけでなく、メモリモジュールメーカーもQVL（認定ベンダーリスト）という一覧を出しており、動作可能なメモリモジュール、あるいはそのモジュールで動作確認が取れているM/Bが確認できるようになっています。原則として、このQVLでいずれかに、あるいは双方とも対応していれば、まずは動きます。仮に動かなかった場合、いずれかのメーカーの保証対象になる場合もあります。

また、前述した「一本目のメモリから溢れたデータを2本目が受け取る場合」に関して、1本目と2本目で動作クロックが異なっている場合、当たり前の事として処理速度のズレが生じる事になります。そして、現時点においてはこの「メインメモリの動作クロック違い」は許容されていない場面がほとんどで、これまたほとんどの場合「遅いほう」に強制的に揃えられることになります。「とりあえず2666MHz一本買って使ってたら、3600MHzが安かったんで一本だけ買ってきた」という環境の場合は、いかに片方のモジュールがハイクロックで動いたとしても、この場合は遅い方の2666MHzに叩き落された上で統一されます。例外、かつ「運が良ければ」という注釈が付きますが、「使ってた2666MHzを強引にOCしたら、3600MHzで動いちゃった」という場合には3600MHzで動作可能かもしれませんが、メモリは単純なクロックだけでなく、複数のレイテンシ（主に4つ併記されている2ケタの数字のアレ）もある為、「動く」かもしれませんが「安定する」かどうかは全く別問題。そもそもからOCメモリ自体が「書いてあるクロックで確実に動作する」という保証が無い為、このようなゴリ押しをした場合は確実に安定性を捨てる事になります。ついでに言えば、各パーツ類に負担がかかってトラブルに発展する可能性も充分にあります。

（大抵の場合「CL」から始まる4つの2ケタ数値が目安）

さて、M/Bやメモリの話ばかりしていますが、ここで最も重要になるのはCPU。メモリコントローラを持っているのがまさにそのCPUで、AMDが先んじてCPUにメモリコントローラを内蔵した後、Intel系でもCPU内蔵になったという経緯があり、現行製品のほぼ全てがCPU内蔵になっているものと思います。その為、対応可能なメモリクロックはCPUの影響を受けるという、「AMD系はハイクロックメモリをぶつけたほうが速い」という内容の真逆となる確認が必要になります。

（ThreadRipper1950X に関するAMD公式スペックシート）

上記スペックシートの通り、TR1950Xに関してはそもそも「最大で2667MHz（「最大メモリー速度」欄）」となっています。実はこの点に関してはAM4系のRyZenも同様で、第1世代（Zen系、1000番台）では2667MHz（RyZen7-1700X）、第2世代（Zen+系、2000番台）では2933MHz（RyZen7-2700X）、第3世代（Zen2系、3000番台）では3200MHz（RyZen7-3800X）とそれぞれ掲載されています。世代が新しくなるにつれてクロックも上昇していますが、これは内部のメモリコントローラの性能向上によるものでしょう。

第1世代では2667MHz（以下ざっくり2666MHzに統一表記します）、第2世代でも2933MHzと、いずれも3000MHzを下回っているにも関わらず、そこにぶつけるOCメモリは3200MHzや3600MHzが良いと言われたのには、AMD製CPUの内部的な構造にあります。

よいこのCPUこうざ：RyZen系の内部構造とメモリクロックの関係

はい、登場なさいました「よいこのこうざシリーズ」。今回は特にRyZenを含めた「Zen系」のCPU/APUとメモリクロックの関係性について。ここでは「実環境で意味があるのか」的な話ではなく、「どういう理屈か」をザックリ解説するとして、まずは大きく2点の事情があります。

・APU（グラフィック内蔵CPU）はメインメモリをVRAMに使う
・InfinityFabricの動作クロックがメモリクロックと連動する

前者は単純な話で、グラフィックボードを別途搭載しない内蔵GPUを使ったデスクトップPCやノートPCでは、ビデオメモリ（VRAM）をメインメモリに置きます（参照：iGPU型ノートPCのVRAM設定について）。その為、メモリクロックが速ければ速いほど、グラフィックス関係のデータ伝送時間が短くなり、特にグラフィックス系の作業やゲームを行う際にはかなりわかりやすく性能向上が見られます。単体グラフィックス（dGPU）に使用されている独立VRAMはGDDR5や同6となっており、速度表記も「MHz」ではなく「Gbps」になっている、帯域幅の違いもあるなどで簡単に比較が出来るものではありませんが、メインメモリの一部をVRAMとして使用する以上、その速度が速ければそのぶんボトルネックを減らすことができる、というアッサリした考え方でだいたいあっています。

問題はもう一点の「InfinityFabric」について。こちらはCPU内部でのデータ伝送を行う「内部配線」と捉えて頂ければわかりやすいかと思います。CPUで処理するデータを送受信する配線。そんな感じ。で、このInfinityFabricの伝送速度（≒クロック）が、メモリクロックと連動している事が、「RyZen系はOCメモリと組み合わせるとパフォーマンスが出る」と言われる所以です。メモリそのもののクロックが上がる事で、メモリ自体の処理も向上するのはもちろんですが、CPU内部を流れるデータ伝送のクロックも上昇する為、最終的にCPUとしての処理速度が向上する、というもの。

「CPUのオーバークロック（OC）」と聞くと、CPUコアやダイの処理速度を向上させ、それに必要な電力を（既定値以上に）与えてゴリ押しする、というイメージがありますが、この「内部配線（InfinityFabric）のクロック向上」も、ある意味でオーバークロックと言える部分かもしれません。この点については実のところ明示的な表記をしている情報が見当たらなかったのですが、少なくともAMDが提示している「CPUにおける最大メモリクロック（最大メモリー速度）」を超えた環境で動作させる、となると、最低でもAMDとしての保証は見込めないでしょう。「OCメモリを使ったらCPUが焼けた」なんて話は聞いたことがありませんが、「OCメモリを安定動作させるのが難しい」というのは、M/BやメモリだけでなくCPUの仕様上の関係もある、というのは認識しておいても損はないでしょう。CPUでもGPUでもメモリでも何でも、ですが、「定格・規定値から外れた状態（オーバー・アンダーとも）での安定動作は難易度が高く、そもそも保証から外れる」という事は改めてお忘れなく。

で、結局どうなったのさ：ようやく本題

はい、ようやくここから本題。増設しましたよってお話で、例によって例の如く #ドスパラ さんにまさかの3日連続通い詰めという迷惑千万な実績……は既に解除済みだったわけですが、まぁ今回もそんな感じで、3日目に気を失ったのは冒頭に記した通り。

（気づいたら手に下がっている袋の中にこんなのが！　的な）

実は今までも使用していたG.Skillのモジュールが最安値だったのですが、2日目に覚悟を決めて買おうと思った際に「2セット売れたからあと在庫2セットしか無いです」と言われて断念。よく考えればとりあえず2セットで64GB環境でも良かったんじゃないのかと思ったりは一瞬だけしたのですが、もうここまで来ると意地と根性の世界。徹底してスロットを埋めてやるべく、2番めのお値段で販売されていたADATA製のモジュールを4セット8本購入しました。パッケージの見た目がややこしくて、「単発32GBじゃないの？」と思ったりもしたのですが、パッケージの裏側にもう1枚入ってます。

ADATAメモリに関しては以前ノートPCで使用した実績があり、かなり安定して稼働してくれていた為にそれほど抵抗は無かったのですが、「チップ製造メーカー」ではなく「モジュール製造メーカー」の為、SSDと同様に使用されているチップは何らかの形で別メーカー製造のもの。ただ、チップ上の刻印はADATA表記となっている為、見た目だけではどのチップメーカー製なのか判別する事はできません。これまた例によって、恐らく出荷時期・ロットによって使用チップが変更されている可能性もあるため、今回の使用チップと全く同一のものが後日ロットの製品で使用されている、という保証もこれまたありません。

QVLに関してはM/B側（ASUS側）には表記がなかったものの、これはM/B自体が第1世代TRとほぼ同時期に発売された為、新しいモジュール製品のテスト結果が追加されていなかった為と思われます。一方、ADATA側のQVLには該当製品が掲載されていた為、これを確認した上で購入しました。

動作クロックは2666MHz製品で、XMP等のプロファイルを持っておらず、かつヒートシンク等の装着も無いモジュールの為、いわゆるOCメモリではなく、ネイティブ動作（最初から2666MHzで動くチップ使用）のモジュールであるようです。一時期は2666MHzでもOCメモリが使われていた（2133MHzベースがメイン）のですが、現行製品では2666MHzでもネイティブ製品が増えてきた様子。上記した通り、第1世代TRに関しては上限が2666MHzである事、またモジュール自体もチップ両面実装のDualRankで、かつ今回は搭載本数も8本と多量になる為、ハイクロックでの高速化は最初から捨てていました。大容量で安定して動作する、という事を第一目標に。

（流石に8本フルスロットは圧巻）

装着自体は自作PCやっていれば大した苦労があるような場所でも無いので、とりあえずサクッとつけてしまいました。ただ、以下2点は気をつけて。

・これまでブランクだったスロットはエアダスターで埃を飛ばしてから
・装着時はパッケージでセットの2枚でチャネルを組むように

埃飛ばしはお約束で、今まで使用していなかったメモリスロットだと案外コレが原因でトラブルを起こすことが多い為。内部端子が細かいこともありますが、基本的にPCの中は埃がガンガン舞い上がる環境である、という事を念頭にしておくと、メモリでもPCIeスロットでも、それこそ最近ならM.2スロットでもトラブルを未然に防ぐ事ができます。一方の「パッケージでセットの2枚で」の点については、今回のような「2枚1セット、デュアルチャネル動作確認済み」という製品の動作検証を無駄にしない為のもの。「セットになっているモジュール2枚でデュアルチャネル環境を作る」を4回（AM4系なら2回）繰り返すように挿してあげましょう。同一出荷時期で同一ロット製品であれば、実際の所そこまで気にすることでも無いのかもしれませんが、せっかくメーカーが検証してくれているのですから、そこは活かす感じで。その他、万が一メモリ周りでトラブルが出た際、「どのスロットのモジュールがセットパッケージだったか」を容易にピックアップ出来る、というメリットもあります。原則的にこのような環境でメモリトラブルが出て、トラブルの出たモジュールが特定できた場合には、そのモジュールとセットでパッケージされていたもう一方も一緒に交換や、場合により保証対応を受ける事になります。かえすがえすも、「搭載本数や同時アクセス本数が多い場合」に関しては、このような組み合わせの管理に関してもキチンと行っておかないと、後々結構面倒になってきます。
（※私の所ではNASサーバで使用中のHDDに関しても、全て導入日時をラベリングした上で、管理OS上でもシリアルナンバーから特定した上でRAIDを組んでいます）

チップメーカーで暗雲、気合を入れてメモリテスト敢行

（あるぇ、2866で動いちゃった……）

装着後にスロット周りを再チェック、ロックの浮きなど基本的なミスが無い事を確認し、（半分くらい祈りながら）PCを起動。とりあえずPOST画面で全容量認識を確認し、まず一旦Windowsまで立ち上げることにしました。

で、上の画像がWindowsのタスクマネージャからの切り出しなのですが、直前まで使用していたメモリで2866MHzの設定を当てていたものがそのまま有効になっており、当たり前のように2866MHzで動作してしまいました。スロット使用本数も正常、認識容量も問題なしと確認した所で、気になっていたDRAMチップのメーカーを確認。

（SpecTek……？）

モジュールメーカーを始め、一通り全ての欄で異常値の検出は無かったものの、DRAMメーカーで「SpecTek」を検出。聞いたことがあるような無いような……。

（せめてFlash外すWebサイト更新くらいしろよ！）

はい、出ましたスーパーマンです。DRAMの他、NANDメモリでも低価格帯製品で採用例が多いチップメーカー。いわゆるリマーク品（刻印書き換えの偽造チップ）の土台に使われるケースが多いチップメーカーです。Webサイトもこの通りひどい有様です。ただ、上の画像の右下に注目。Micronのコピーライトが入っています。これに関してはウソでもなんでもなく、SpecTekはMicron（Crusialブランドの製造元）の子会社にあたります。ザッと調べた限りですが、Micronで製造したチップの検品を行うのがメインで、そこで「Micronブランド」として販売するには品質が足りない製品を弾いた上で改めて選別し、SpecTekブランドとして販売しているとの事。選別の具合にもよるようですが、単純にSpecTekだからといって全部がダメ、というわけでも無いようで、そういった「ハネ品」の中でも動作上比較的安定しているものを流通させているようです。ただ、日本の自作PC業界で一時期問題になった「ドスパラオリジナルSSD」の際に登場したのが「IntelチップだとかMicronチップだとか」という結構な問題になった事で、SpecTek製品は結構話題（問題）になっていました。

まぁ16GBモジュールでもかなり安価な製品（購入時点で下から2番め）を選んだこともあって、「中身はSamsungかHynixあたりかなぁ」とか思ってたりはした（例のE495の16GBはSamsungでした）のですが、ここへ来てまさかのSpecTek。このへんはもはや偏見でしか無いのですが、「ドスパラで購入したメモリモジュールがSpecTekだった」という時点でちょっと斜めに構えてしまいました。ただ、今回に関してはSSD事件とは全く別のお話で、「ドスパラがADATA製のメモリモジュールを販売していた」だけにすぎない事、ADATA側がチップ上の刻印含めチップメーカーを原則非公開としていたという事なので、先のSSD問題と一緒くたにするのはいくらなんでも強引で早計なお話です。また、この件に関しては私が「ドスパラアンバサダー」としてレビュー等を行っているからどうこう、という話でも無く、あくまでも過去に発生した事象と今回手元に来た製品の内容として掲載したにすぎません。その点はお間違い無いよう。

というわけで、そうは言ってもなんとなく悶々とした感覚ではありましたが、とりあえずメモリテストを走らせる事にしました。こちらはお約束のmemtestを使用。旧バージョンではなく、UEFI風インターフェイスとなった新バージョンです。

USBメモリに書き込んだ後、USBブートにて起動、ひとまずフルテストを4周（フリーバージョン上限）で回しました。なお、初期テストの為、一般的な解説サイトでは「メニューから外すのを推奨」とされている「Hammer Test」も実行しています。その為、とんでもない時間がかかりました（1周4時間半くらい）。Hammer Testとはなんぞや、なのですが、「row hammer」というDRAM特有の不具合を特定する為のテストで、ソフトウェア的なバグ（メモリチップコントローラ等の誤動作）では無く、電気的、ハードウェア的な不具合（メモリ内で動く「電荷」の問題）を検出するもの。これが発生している場合、単純にハードウェア的な不具合、今回で言えば初期不良と判定される他、場合により継続使用する中でセキュリティ的なリスクを抱える事にもなります。今回は特に本数が多く、サイズも大きい為、特に注意して見なくてはいけない部分という事で、時間がかかってでもテストを行う事にしました。

（ブレブレながら1周目終了後の画面。エラー検出無し）

先日のE495の際にも走らせたのですが、気づいていなかったのが「CPUスレッド全部使ってテストが出来る」という事。今回は16コア/32スレッドという事で、CPUの32スレッド全てを使って一気にリード・ライトを行ってテストを回してくれました。テスト内容によってはシングルスレッドに限定されるのですが、マルチスレッド対応のテストに関しては明確にテストスピードが向上していた様子。また、ちょっとおもしろいデータとして、画面左上の各メモリステータス部分にある「L1/L2/L3キャッシュ（CPU内部）、及びメインメモリ」のアクセス速度について、CPU内部にあるL3キャッシュよりも、外部インターフェイスを経由するメインメモリのほうがわずかながら速度が速い、というデータも取得できました。L1/L2キャッシュに関しては圧倒的に速いのですが、L3までくると恐らく「外部（≒メインメモリ）との連結バッファ用」という扱いになるので、外部メインメモリと近い速度で動作している、という感じなのかもしれません。基本的にはいずれのキャッシュ（≒メモリ）も順を追ってCPUから離れた位置に配置される為、その分スピードは落ちていきますが、その変わりというか、サイズは大きくなっていきます。TR1950Xの場合はL1が96KB、L2が512KB、L3で32768KB（≒32MB）と、L3キャッシュですら32MBという領域。それ以上のエリアがあっても、CPUの処理待ちをする事無くデータ処理が完了する為に不要、という事になります。

テストを無事通過、実使用環境での安定性テストも良好

（AfterEffetcs自重しろ）

そんなわけで無事にテストも通過し、メーカーはともかくとして正常動作が可能であると判定出来る結果であった為、ひとまずそのまま継続使用する事としました。まずは一番使用頻度が高く、かつメモリ使用量も尋常じゃないAfterEffectsにて、「メモリ使用上限96GB」に設定してテスト。これは冒頭に記した通り、かつ上の図に出ている通りなのですが、「テキストトランジション系のプロジェクトを開いたら16GBくらいアッサリ食う、プレビューを走らせるとリニアに使用率が上昇し、設定上限ギリギリからは水平飛行」という挙動。これを数回繰り返したり、プロジェクト自体を閉じて開いてを繰り返したり、他のソフトウェアでメモリを埋めた状態でテストしたりと、数パターンのテストを行いましたが、いずれも挙動に変化は無く、「PC使用上のどのようなメモリ使用状況であっても、安定してほぼ同一の挙動を見せる」という点で、メモリ全域に対して安定性を確保出来ると判断出来る内容でした。

「なんかメモリを食いまくるようなの、他にあったかなぁ」と悩むくらいにデカいメモリ領域のテスト、「あるじゃん！」と見つけたのがVMWare。バーチャルマシン起動状態でのテストも行いました。

（VM内でWindows10 64bit起動直後。思いの外メモリ食ってない）

VMWareでのテスト用に用意しておいたWindows10環境で、VMとしてのメモリ使用量を64GBに設定、そのまま起動させた直後が上の図。ホスト側から見たメモリ使用量でおよそ70GBとなっており、まさかホストが6GBのメモリ使用量で動いているはずも無く、こちらは必要なぶんだけメモリを食いに来る（予備領域をそれほど置かない）動きを見せてきました。テスト環境という事で基本的に何にも入っていないVMだったのですが、たまたまDiscordが入れっぱなしだったのでとりあえず起動してみたのが以下。

（ホストからの使用量が81GB）

Discordに限らなかったのですが、VM上で何らかのソフトウェアを走らせた時点でガバッとメモリを食いに来ます。グラフがフラットになっているのと、このテストの時点で何故か「VM上でのメモリ使用量」を計測していなかったのが痛かったのですが、ホスト側で81GB使用、仮にVMが設定値上限の64GBをフルに使っていたとして、ホストは17GBの使用量で動作、と考えると、案外順当な数値ではあります。よっぽどVMと同時に色々立ち上げていたりしない限り、実質的なWindowsのメモリ使用量なんてこんなモンです。

で？　快適になったの？

場面次第ではありますが、快適になりました。それこそ動画編集でストレージにキャッシュを置く必要がなくなったとか、通常のソフトウェアをポンポン立てながら「あ、そういえば」と思って重たい系のデータを開いた時とか、それこそAndroidエミュレータを複数常時稼働させたりとか、「CPUのスレッドも食うけどメモリも食う」という使用用途においては、例によって「スペックのバランスが取れた」状態になった為、動作も安定し、使い勝手も極めて良好です。またサイズが128GBという、いくらなんでも通常環境からは飛び抜けすぎたサイズなこともあって、CPUと相まって「VM上で一般的なPCの動作を（VGAはともかく）再現する」というトラブルシュートやレスキュー時の対応可能なエミュレート範囲も広がりました。そういった面でのかなり限定された場面、という意味ではありますが、全体的なバランスが上積み状態で安定した為、なかなかに快適です。

その一方で、「じゃあ誰にでもオススメするか」と聞かれれば、二つ返事で「しねぇわ」と答えるような環境でもあります。モジュール枚数も多く、同時アクセスチャネル数も多く、全体的な構成を見ても確実にピーキーな部類に入る構成になりました。そもそも「ワークステーション」として販売されている製品の価格が比較的高めに設定されているのは、パーツ単体が高価なだけでなく、それらを安定させる為の「パーツの組み合わせ・設定出し」といった、それほど単純な理由では無いこともあるので、これを自作環境でイチから全部自分でやる、というのは、よほど設定慣れやパーツ構成の組み合わせに慣れている方でなければ（或いはそうであっても）オススメはできません。特にメモリはほんの少しコケただけで簡単に作業中データが吹き飛ぶような部分でもある為、今回のように「価格をケチって容量に振った」ような増設自体、リスキーな選択肢であるわけです。

そんなわけで、そもそもThreadRipperなんぞ使ってる人に「一般人」がいるとは到底思えませんが、「逸般人」であっても、全スロット埋めきるまでいかず、第1世代なら16GB*4の64GBあたりで留めておくのが安牌かなと思います。第2世代以降で256GBくらいまで（モジュール単体32GB*8枚）対応してきていますが、よっぽど容量が必要でないのであれば、クロックを合わせた上である程度品質が担保されたモジュールを使って、より安定性を出す方向で検討されたほうが良いかなと。「やってみた」的な（今回の私のような）感じでお試ししてみるのは自由ですが、動かなかった時のリカバーは死ぬほど苦労しますよ、と警告しつつ、どうにも締まらないですが〆にします。