メモリの規格はここのところ3～5年で変遷してきた。近年のメモリは20世紀末に現れた１クロックで1つのデータを転送するSDRAM（Synchronous Dynamic Random Access Memory）を祖とするが、その後１クロックで2つのデータを転送する「Double-Data-Rate」ことDDR、さらにその倍の１クロックで4つのデータを転送するDDR2、さらに倍の１クロックで8つのデータを転送するDDR3とここまではほぼ順調に約10年ほどで来た。

しかしそこからが長かった。

次はさらに倍の「１クロックで16つのデータを転送」する「DDR4」という事にはなっていたが、技術的な問題も多くなかなか生産まで辿り着けなかった。DDRからDDR3までは同じ路線で微細化・高速化さえ行っていれば達成できたものが、壁に当たり、別の方法を探らなければならなかったためだ。

そして策定された規格はスロットサイズは従前のDDR3と変わらないが、接点はDDR3の240ピンから284ピンに増加し、誤って挿すことがないよう、切り欠きの位置も変更されている。また、特徴的なのはベースグレードで2133MT/secという高速動作を実現するのにも関わらず、DDR3の1.5Vより低い1.2Vで動作するということだ（今までダイ内部で昇圧していた、2.5Vの電源を外部から供給する必要はあるが）。

面白いのは接点側の中央が盛り上がっており、直線ではないこと。

逆挿し防止のため、切り欠きの位置は中央ではない。

逆向きには挿入できない。

これによりベースグレードでもDDR3をしのぐ動作周波数を達成しながらヒートシンクなどはより小さくなっており、今までの感覚で見ると拍子抜けしてしまう。

低電圧版の地味なスプレッダでも抜き身のDDR4と比べればゴツイ

高さはほとんど変わらない

メモリの効果を試すにはメモリの量を変えていき、アプリケーションにどのような変化を与えるかを検証することにした。比較的重いベンチとして定評がある？Futuremarkの3DMark、2014年10月24日リリースのVersion 1.4.780で「Fire Strike」をメモリをそれぞれ64GB、32GB、16GB、8GBと変化させながら実行した。

しかしここで予想外の結果を得ることになる。

順番を間違えたか何度も確認した

予想外に64GBの結果が一番と言って良いほど悪い

スコアがメモリ容量に比例しないのだ。いや最大容量の64GBは明確に悪くなっている。4容量の中で一番よかったのは実は16GB。続いて32GBで、僅差でなんと8GB。最も悪いのがフル積載の64GBだった。個別にスコアを見るとPhysics系だけはわずかに8GBの方がスコアが悪いが、GraphicsおよびCombined系のテストでは、64GBが最低スコア。ということはこのテストは重いとは言いながらもメモリは16GBで事足り、あとは認識やデータ分散・統合の手間を増しているだけなのであろうか。ベンチマークの要求性能の問題で、「頭打ち」になり、メモリの広さが活かせない、というのは想定内だったが、悪化というのは予想外だった。

では、とマルチスレッドを活かせる代表的な作業としてエンコードを試すこととした。それも「マルチスレッドを活かせるエンコードアプリを使用する」のではなく、同時に複数個のプログラムを立ち上げ処理させる、という方法。

使用アプリは当初、対応形式が非常に多い音声・動画 エンコーダとして有名で日本語のサポートも多いMediaCoder x64のみを使用しようと考えたが、同じアプリを同時に走らせると異常終了して落ちてしまったり、途中でエラーになってしまってエンコードがきちんと終了せず計時できなかったので、もう一つアプリを用いることとした（MediaCoder x64の同時スタートは8つまで。途中で異常なく間違いなく終了できるのは6つまでと判明）。なお、MediaCoder x64にはNVIDIAのCUDAを用いるセッティングもあるが、今回はCPUのみを用いる設定にしてある。

追加で使用したのはこれもプリセットプロファイルの充実度で定評があるXMedia Recode。これは変換途中は進捗度合いの棒グラフしか示されないあっさりとしたエンコーダーだが、複数立ち上げが安定して可能だった。

いくつか組み合わせを検証すると、MediaCoder x64を4つ、XMedia Recodeを4つ立ち上げ同時（手作業なので「ほぼ」同時だが）にスタートさせても安定してエンコードができる事がわかった。

そこでVHSビデオからhoestechのVHS to DVD

を用いてキャプチャーした227MBと292MBのmpeg4ビデオファイルを、ノーマルの720x480からフルHDサイズに縦横比保持のまま拡大しつつFlash用のFLVビデオ形式にエンコードした。

こういう感じで2つのアプリを4つずつ立ち上げて検証

今回の検証では、48GBを入れた8GBメモリを使う場合にとることができるすべての組み合わせ（8GB、16GB、32GB、48GB、64GB）で検証した。

【8GB】

CPU使用率はいっぱいいっぱい。メモリも（最大）7.9GB使用

【16GB】

後の検証から考えると（最大）12.6GBに抑えてフリーメモリを空けているようだ

【32GB】

（最大）16.2GBの使用で、メモリは半分空いている

【48GB】

16.3GBとほとんど32GB時と変わらないが、スピードはアップ

【64GB】

メモリ最大使用量は16.5GBとほぼ頭打ち。CPU側の余力をつくれば他の作業もできそう。

8GBはアップアップという感じだったが、16GBで落ち着き、32GBまでほぼリニアに性能が上がった。48GB以上はCPU側がボトルネックなのか、大きなスコア改善は得られなかったが、メモリの使用率は大きく下がった。

CUDAなどエンコード補助機能でCPU負荷を軽減させてやれば8本同時のエンコードという負荷の高い作業時においてもメモリ使用量上はまだ他の作業の余力がある広さだった。

結果の纏め。メモリ容量依存的に結果はよくなるが．．

この用途では32GBでほぼ頭打ち。コストパフォーマンス的には最適解は32GBか？

今回新規格のデスクトップPCメモリ、DDR4 SDRAM Crucial CT8G4DFD8213を検証した。
より高周波数で動作し、クロックあたりのデータ転送が多くなっているのにもかかわらず、低電圧で動作するというように、いままでの延長線ではない工夫がみられた。またメモリ規格変更時にいつも取りざたされる相性問題は、8枚フル搭載時も含めて搭載容量の影響を受けなかった。

ただ、これだけの大容量をソフトの方が生かし切れないのか、使用目的によってはスコアが容量に沿って上がらない現象が観察された。一方きちんとメモリの広さが活かせるソフトでは容量に比例した処理能力が得られた。

CPU側の進化が周波数向上によるピーク性能追求から、マルチスレッド化による並列処理に移ってきているが、そんな並列処理時には複数枚積んでも安定しているDDR4 SDRAMというのは今後の主流になっていくだろう。現在はまだプロシューマークラスといえるX99プラットフォームでしかサポートされないが、今後現在のZ97クラスに採用されたときにはその性能で、H97クラスのMini-ITX板などへの採用ではその低電圧で、今よりも一段向上したメモリ性能を提供してくれるだろう。

【CT8G4DFD8213仕様】
UDIMM 288-pin
8GB
2133MT/s
Dual
1.2V
COMP CONFIG　512M x 8
CL15