ではそこまでの間、何か弾があるのか？ というと「何もない」というのが結論になる。Xeonに関して言えば、まず2019年初頭にCascade LakeとCascade Lake-APが投入される。

2018年8月に開催されたData-Centric Innovation Summitにおける説明では、2018年中にまずCascade Lakeが出荷される予定だった(Photo08)。ただ現時点でもまだCascade Lakeは出荷されておらず、これは2019年第1四半期中にCascade-Lake APと一緒にリリースされると思われる。

  • Photo08:ちなみにこれを説明したのは(AMDからTelsa経由でIntelに移籍した)Jim Keller氏(SVP&GM, Silicon Engineering Group)である

Cascade LakeはPhoto08にもあるように、Optane Persistent Memory(DIMM上にDDR4とOptane Memoryを混在させたもの。Optane Memoryを大容量のDRAMとして利用できる)のサポートと、VNNI(Vector Neural Network Instructions:AVX512命令の拡張版で、CNNの処理に向けてVPDPBUSD(8bit)とVPDPWSSD(16bit)という２命令が追加されたもの)のサポート、それとセキュリティ拡張である。

セキュリティはSpectre/Meltdownに対応したもので、これはWiskeyLakeなどにも搭載されている。となると、Cascade Lakeをコンシューマ向けに持ってくる意味はほとんどないことがわかる。

Cascade Lake-AP(Advanced Performance)は、このCascade Lakeを2ダイ、1つのMCM上に載せた製品(Photo09)である。こちらはもっとコンシューマに無縁だ。Cascade Lake単体は、Core-Xに降りてくる可能性はなくもないが(Xeon W-3175Xの後継とかにはありそうだ)が、Cascade Lake-APが降りてくる可能性は皆無だろう。

  • Photo09:こちらは詳細は語られていないが、7nm EPYCへの対抗馬であることは明白である。ただ問題は、恐らく1モジュールで300Wを超えるTDPになると思われ、水冷は必須となるだろう。サーバー製品に使うにしても、結構扱いが難しそうだ

これに続いておそらく2019年の後半に投入されるのがCooper Lakeである。こちらはBFLOAT16(16bitのFloatであるが、IEEE-754で定義されるBinary16と異なり、仮数部8bit、指数部7bit、符号1bitというCNNに特化したフォーマットのもの)のサポートである。

要するにDeep Learningの学習の性能を引き上げるためのもので、やはりコンシューマ向けには全く関係ない。

ではコンシューマ向けはIce Lakeまで本当に弾がないのか？ というと、少なくとも筆者が知る範囲ではその通りである。もちろんプロセスをいじって、さらに消費電力を引き上げることを許容して、1bin程度動作周波数を上げた製品が投入される可能性はある。

また、確度の低い噂では14nm+++(この話は最近ほとんど聞かなくなった)を使い、10コアのCoffee Lake Updateを作っているという話もちらっと出ている。この10コア版では、ついにRing Busが2重になるそうだが、どう考えても与太話以上の話ではないように思われる。

普通に考えれば、そうでなくても現状で逼迫しまくっている14nmのラインをさらに圧迫しても仕方がないわけで(この逼迫が解消されるのは2019年後半に入ってからだし、そのころにはそろそろIce Lakeが見えてきている)、あるとしてもBackup Plan(またもや10nmがコケた、という事態に対応するためのもの)でしかないだろう。

まぁ仮にこのBackup Planが必要になるような事態におちいった場合、IntelのCPUビジネスそのものが揺らぎそうではあるが。

そんなわけでIntelの新製品をお待ちのユーザーは、基本的には2019年末のIce Lakeまでじっと我慢の一年、ということになりそうだ。

AtomとCoreのHybrid実現はもう一山ありそう

ところでプロセスのところで紹介した、AtomとCoreのHybrid(Photo10)についてもちょっと説明しておく。Mobile的にはこうしたコアの組み合わせは理にかなっている。

  • Photo10:Foverosのコンセプト画像

Androidの世界ではArmのbig.LITTLEが広く普及し、実際に待機時にはLITTLEコアで消費電力を落としつつ、アプリケーションの稼働時にはbigコアで高い性能を、という使い方が可能になっている。

Intelの10nmプロセスは(7nmのEUVほどではないにせよ)製造コストは高くなるだろうから、I/OなどはAtomと一緒に14nmで作り、これと10nmで製造したCoreを3D PoPとして構築することは間違ってはいない。

そんなわけでハードウェア的には正しいアプローチの1つではあるのだが、問題はハードウェアではなくソフトウェアの側にある。

Armはbig.LITTLEのアーキテクチャを2011年に発表した。ところが実際にこれが広く利用され、その価値が見いだされるようになったのは2015年とか2016年である。

何故かというと、スケジューラの側の問題があるからだ。負荷が高ければbigコアに、負荷が低ければLITTLEコアに割り振る、という作業はOSのKernel内部のスケジューラに手を入れない限り実現できない。加えて、どうやって負荷の高低を判断するかとか、どのくらいの負荷状況が続いた段階で切り替えるのがオーバーヘッドが少ないか、など問題は色々ある。

Armは当初、OSのKernel Schedulerには手を入れずに、これを実現する方法を模索したものの、最終的にはSchedulerをいじらないと実現できないという結論を出した。そこからLinuxカーネルの開発に積極的にCommitする形でこれを達成した。

そうした開発に、4～5年掛かった、という話である。Photo10のCore/Atomのbig.LITTLEであるが、いまのところWindowsのスケジューラにそうした機能が入っているという話は全く聞かない。

あるいは、いまIntelのソフトウェアチームがMicrosoftに大量に出向して、Kernelのパッチ当てをしているのかもしれないが、ソフトウェア的にこのあたりがいつサポートされるかが鍵となる。

付け加えると、オリジナルのbig.LITTLEでは、big⇔LITTLEの切り替えの際に、それぞれのCPUクラスタにDedicateされた共有L2キャッシュの内容をコピーする動作が必要だ。

それもあって、2017年に発表されたDynamIQではL2はコア側にDedicateされ、共有キャッシュはL3としてCPUクラスタから切り離して存在するという構造になった。

この辺りをPhoto10の環境でどう実現するのか。現時点でちょっと不明である。P21222 IO/SoCの側に大容量L3があり、それをTSV経由でP1274 Computeがアクセスするという構造かもしれないが、MCMよりマシとはいえTSV経由だと消費電力も大きいしLatencyも馬鹿にならない。

何というか、コンセプトとしてのPhoto10の構成は理解できるのだが、実際の製品に仕立てるにはまだ一山ありそうな感じがする。