発表されたLakefieldはカスタマイズ版Windows10向け インテル CPUロードマップ

今週はAIプロセッサーの話はお休みいただき、Lakefieldを取り上げたい。Lakefieldに関してはジサトライッペイ氏による第一報がすでに上がっているのでご存じの方も多いかと思う。

この連載でも538回でLakefieldのSmall core側であるTremontの内部解説をしているが、今回は発表でわかったこととまだわからないことをまとめて紹介したい。

ダイサイズは82mm2？

通常インテルは製品をリリースするとそのダイ写真なりウェハーイメージなりを紹介してくれるのだが、現時点でLakefieldに関しては公式(News Roomページ)では未公開である。

実はこれ、同じものを入手できないかインテルに掛け合っているのだが今のところ返事がない。なのでいまいち真偽のほどは不明ではある。ただ実は今年5月、imgurにLakefieldのダイ写真が上がっており、これのタイトルが“Intel LKF 82mm2”となっている。

この2枚を試しに重ねた結果が下の画像で、見事に一致しており、おそらくはどちらも正しくLakefieldのものと思われる。

左上と右下がImgurの、右上と左下がSchilling氏のもの

一応このどちらもがLakefieldのダイ写真だと仮定した場合、ダイサイズは82mm2というimgurの数字がわりと信憑性をもつものになる。

仮にこの82mm2が正しいとして内部解析をしてみたい。下の画像はimgurのイメージに、想定されるレイアウトを重ねたものである。

左上のブロックと左下ブロック、どちらがLLCかはかなり悩んだのだが、おそらくダイ左端中央にあるのがPCI ExpressのPHYで、となると左上はPCI ExpressのRoot Complexその他と考えられるため、左下がLLCと思われる

全体の４割近くをGen11 GPUが占め、中央にSunny Cove×1(下側)とTremont×4(上側)が並び、左側にUncoreの4MB LLCその他が集積される、わりと整然とした構成である。この画像からそれぞれのエリアサイズを推定すると、以下の表のようになる。

Sunny Coveのエリアサイズは、Ice Lakeでは6.9mm2と伝えられているが、これはLLCのSliceを混みにした数字で、LLCなしでは4.7mm2程度とされるので、ほぼ今回の推定と一致することになる。

そしてここから今回Tremontコアのエリアサイズが初めてわかったわけだが、1つあたり1mm2未満、4コア合計でも3.7mm2ほどでしかない。

もっとも実際には2つのTremontコアのクラスターの間にインターコネクトが入っており、4コア全体でのエリアサイズで言えば5mm2をやや超えるほどになる。

とはいえ、4コアのTremontと1コアのSunny Coveがほぼ同等のエリアサイズになるわけだ。性能/エリアサイズ比では悪くない結果だと思う。

ちなみにLakefield自身は下の画像のように、Compute DieとBase DieをFoverosで結合し、さらにDRAMをPOP(Package on Package)の形で搭載する構造なので、別にBase Dieが必要になる。こちらのダイサイズは不明だが、おそらく同等もしくはやや大きい程度に抑えられていると思われる。

Lakefieldの構造。これは昨年5月に開催されたInvestor Meetingの際の公開資料

メモリーは4GBと8GBの2種類が存在 GPUコアは最大500MHz駆動でしかない

イッペイ氏の記事でも簡単な表が示されているが、すでにark.intel.comに2製品とも登録されているので、これを元に若干追加したのが下表である。

まずメモリーについて。どちらの製品もLPDDR4x-4267チップを4つ搭載しており、合計容量は4GBないし8GBとなる。実はこれ、わかりにくいのだが、ark.intel.comでCore i5-L16G7とCore i3-L13G4のOrdering and spec informationを開くと、4GBと8GBの2種類のSKUがあることが明示されて初めてわかった。

それはともかくとして、ark.intel.comの方では最大メモリー帯域が34GB/秒とされており、ここから合計で64bit幅構成とわかる。前述したLakefieldのダイ写真で、ダイの四隅にLPDDR4x 16bitとしてある部分がメモリーコントローラーであり、それぞれ1チップのLPDDR4xチップとつながる構成になると思われる。

次にGPUコアの動作周波数について。定格は200MHz駆動、Max Turboでも500MHz駆動でしかない。インテルによれば、これでも3DMark 11の結果をCore i7-8500Yと比較してほぼ2倍のスコアだとしているので、検証してみたい。

Core i7-8500YはIntel UHD Graphics 615(24EU)構成で、定格300MHz/Turbo 1.05GHz駆動である。ラフに言ってGPU性能はEU数×動作周波数に比例するので、Core i7-8500Y：Core i5-L16G7は定格同士なら1：1.778、Turboの場合で1：1.270といったところで微妙に2倍には届かない。

メモリー帯域についても、Core i7-8500YはLPDDR3-1866ないしDDR3L-1600のサポートだが、メモリーバスは128bit幅なので最大メモリー帯域は33.3GB/秒、対してCore i5-L16G7は上にも書いたように64bitバスなので、帯域は34GB/秒どまりであり、大して大きな差ではない。

もっとも3DMark11のスコアは単にGraphicsだけでなくPhysics(つまりCPU)性能も加味されるから、このあたりでぎりぎり2倍というあたりだろうか。

ただせっかくの64EUがあまり活用されていない(これなら半分の32EUにして、その分動作周波数を上げた方が効果的に思える)気もするのだが、このあたりの損得勘定はかなり微妙なものになりそうだ。

この話はTDPにも絡んでくる。今回発表の2製品は、TDP 7Wとされている。実はこれも怪しい、というより「現在出荷中の2製品のTDPは7W」というだけで、他のSKUもありそうだからだ。

昨年のInvestor MeetingにおけるMurthy Renduchintala博士のスライドの脚注に、“LKF 5W & 7W Configuration”と表記されており、また“PL1=5W & 7W”という表記もあることから、少なくともTDP 5WのSKUも存在しそうである。

加えて言えば、もっと消費電力の高いSKUの可能性もある。実際、もう少し消費電力を引き上げることを想定している節も見受けられる。上でも少し触れたが、500MHz×64EUと1GHz×32EUは、今のインテルの10nmプロセスであればおそらくほとんど消費電力は変わらない。

変わるのはもう少し動作周波数を上げた場合で、例えば700MHz×64EUと1.4GHz×32EUでは、明らかに1.4GHzの方が消費電力が大きくなると予想されるためだ。

つまり、もう少しTDP枠を引き上げることを前提に、64EUにして動作周波数を抑えめにして性能を引き上げる構成を考えていると思われる。

話を戻すと、PL1 Tau(Power Limit 1 Time)は現在公開されていない。このあたりの詳細はデータシートが公開されるのを待つしかなさそうだ。

ハイパースレッディングを無効にしたのは ARM向けのスケジューラーを流用するため

今回のLakefieldは、Surface Neo向けというか、カスタマイズ版Windows10向けのSpecial Editionではないのかという気がする。その根拠は2つあって、まず1つはコア/スレッドが5/5構成なことだ。

連載538回でも書いたが、マイクロソフトはARM版Windows 10でbig.LITTLEをサポートしており、このスケジューラーをそのままx86に持ち込むのは可能だろうとしたわけだが、どうも本当にそのようだ。

なぜかと言えば、現状ARMのコアは自動車向けおよびサーバー向けの一部製品を除くとSMT(Simultaneous Multithreading：同時マルチスレッディング)に対応していない。これはQualcommのチップも同じである。

一方SunnyCoveにしろTremontにしろ、SMT(ハイパースレッディング)には標準対応である。もし今回マイクロソフトが、Lakefield向けに新規にスケジューラーを起こしたとすれば、当然SMT対応にするだろう。実際見かけ上はBig coreが2つ、Little coreが8つのシステムと扱えるからだ。

ところがbig.LITTLEは最大でもコアが8つまでしか扱えない(実際、QualcommのSnapdragon 8cxはKryo 495×8の構成である)。ハイパースレッディングを無効にした理由は、まさにARM向けのスケジューラーをそのまま流用したいためではないかと思われる。

今回のプレスリリースを読むと、中に「ハードウェアによりOSスケジューラーにガイドを提供：CPUとOSスケジューラーがリアルタイムに通信して、アプリケーションが必要とする正しいコアに割り当てられる」とあるのは、おそらくbig.LITTLEと同等のAPIをLakefieldが提供しており、Windows 10はこれを利用してスケジューリングを行なうものと思われる。

もう1つの理由は拡張命令である。SunnyCoveはSSEに加えてAVX/AVX2/AVX512までに対応しているが、TremontはSSE 4.2止まりである。したがって、AVXを利用するアプリケーションが来たらSunnyCoveに割り当てるような形になるだろうと予想したのだが、そうではなくLakefieldそのものがSSE 4.2までの対応になっている。

つまりSunnyCoveコアを搭載しているにも関わらず、AVX命令が一切使えないことになってしまったわけだ。AVXだけでなく、連載525回で説明したGNAも無効化されていると思われる。理由はこれもbig.LITTLEである。

ARMのbig.LITTLEでは、Big coreとLittle coreがサポートする命令セットは完全に同一でないといけない。この制限がLakefieldにもモロに引っかかることになったのだろう。

当初はAVX命令が来たらフックを掛けてSunny Coveコアにスレッドを移動する、という芸当をスケジューラーに組み込むと考えていたのだが、そうした芸当は一切不可能ということになる。

ただこれはbig.LITTLE互換のスケジューラーの制限であって、それ以外のスケジューラーを開発すれば、SMT対応、AVX対応も可能ということになる。

Linuxカーネルなどに向けて、そうしたカーネルスケジューラーを内部で現在開発中なのではないか、という気もする。

それが用意できたら、フルスペック(?)のLakefieldが登場するという可能性もありそうだ。もっとも、そうした製品が市場からどこまで要求されているのかは「？」である。

今回の構成を見ていると、なんとなくSurface Neo向けだけで終わりそうな予感もある。果たしてそれ以外の採用事例が出てくるだろうか？