昨年末に、自宅PC（メイン）のメモリを上限の16GBに増設しました。メモリの上限はマザーボードによって異なり、自宅PC（サブ）は上限が8GBでした。自作PC用に流通しているマザーボードがどれだけメモリが積めるのか調べてみると、今時点での主流は32GBで、一部64GBの製品が出ているという状況です。
サーバー機のスペックを調べる前までは、特に根拠はなく勝手に〜128GB位かなと思い込んでおりました。そして、近い将来物理メモリが1TB台になったらその上で動くプログラムの作り方はどうなるんだろうか？ といったことを考えてました。
実際に主要PCメーカーのハイスペック・サーバー機を調べてみると、8wayと呼ばれるCPUソケットが8つあるタイプで物理メモリは128DIMMスロットで16GBをフルに積めば2TB、32GBを積めば4TBというのが存在しました。
また、8way（8CPU）に対応するCPUでコア数がもっとも多いXeon E7-8870では10コア20ハイパースレッドがあり、8個フル搭載すると80コア160スレッドマシンになります。
このハイスペックPCは、値段も1〜2桁違いなのでたぶん触る機会はなさそうですが、すでに計算機リソースは、100超*1のCPU並列とテラバイトの物理メモリが利用可能な時代になっているんですね。
プログラミングの変化が必要？
プログラムで利用可能なメモリが処理したいデータ全体より小さい、というのがよくあるケースの一つです。
例えば、Windows OS(32bit)で動くプログラムの場合、プログラムのコード・データ、スタック、ヒープ等合わせて最大2GBに制限されます。最近のプログラムは多数のDLLを引っ下げ肥大化しているので、通常データを置く場所となるヒープに割けるサイズは1GB以下になることが多いでしょう。
このケースでは、処理対象データはディスク(ファイルやRDBMSなど)に格納し、データの一部を随時メモリに取り出して処理します。そのため、メモリに置くデータは小さく、データ構造を考えずにシングルCPU(コア)でぶん回してなんとかなってました。それよりファイルから必要なデータを取り出し、更新する性能がプログラムの処理に影響します。CPU、主記憶、補助記憶から構成される教科書的な構成です。
ところが、テラバイトメモリの計算機環境となると、上述のケースでデータ全体がすっぽりメモリに載ってしまいます*2。すなわち、データをすべてメモリに展開してからデータ処理を行うことが可能になります。
メモリ上に置いたデータを処理対象とするので高速になるはずですが、データ構造を考えずにメモリ上にデータを並べ、従来のシングルコアぶん回しのやり方でプログラムを作った場合、高速に処理することができないかもしれません。もしかするとメモリがふんだんにあっても、ファイルに置いたデータをDBMSに取り出してもらった方が、自分で作ったメモリ上の下手なデータ処理より性能がよいので速い、ということになるかもしれません。
テラバイトメモリと100CPU（コア）という計算機リソースにおいては、プログラミングのスタイルを変える必要があるのではと思います。シングルコアの性能が大して上がっていないので、メモリ上に配置した大きなデータを並列処理するプログラミングに変えていくのがこれからの有力な方法になるのではと思います
変化の無いプログラミングの世界
蛇足な気がしますが、テラバイトメモリ・100CPUの計算機リソースを、仮想化によって多数の小計算機集合体として、個々の仮想化計算機は今までどおりのしょぼいリソース（数個の論理CPU、数GBのメモリ）とすれば、プログラミングの変化を強いられず、当面は従来のスタイルにとどまることもできます。
