「Lunar Lake」Deep Diveレポート - 【Part 3】Platform Controller Tileについて

画像提供：マイナビニュース

前回と前々回で、Lunar LakeのCompute Tileに関連する部分はほぼ説明が終わったので、今回はPlatform Controller Tileに関連する話をまとめてご紹介したい。
Thread Director

Alder Lake世代で導入されたThread Director。Alder Lakeにおける動作はこちらで、Meteor Lakeにおける動作はこちらでそれぞれ説明しているが、コア構成が異なる事もありLunar Lakeでは当然振る舞いが変わってくる。まず基本的な動き方の違いがこちら(Photo01)。簡単にまとめると

Raptor Lake: まずP-Coreが処理を行い、その負荷次第でE-Coreに移すが、定期的にE-CoreのThreadをP-Coreに移動する
Meteor Lake: まずLP E-Coreが処理を行い、負荷が高ければCompute TileのE-Coreに、それで足りなければThreadをP-Coreに移動する。
Lunar Lake: まずE-Coreが処理を行い、それで足りなければP-CoreにThreadを移動する。
という形になる。

このMeteor LakeとLunar Lakeでどういう風に負荷分担が変わったか？ ということで、通常のWindowsのTask(Photo02,03)、あるいはTeamsでの動作状況(Photo04,05)を見るからには、「できるだけP-Coreを使わない」Schedulingが成されている様に見える。これが成立するのは前々回で述べたようにE-Coreの性能(というか、IPC)が大幅に引き上げられ、E-Coreで十分賄える処理の範囲が広がったため、と考えられる。というか、ここまで性能が高ければもうP-Core要らないんじゃないかと思わなくもないのだが、とは言え電力の制約でピーク性能が出ないのがE-Coreの実装なので、このあたりは仕方ないのだろう。

話を戻すと、Lunar LakeにおけるThread Directorの改良目標とその方法がこちら(Photo06)。この第一項目目である"Optimize right workload for right core"は、E-Coreの性能を大幅に引き上げて、そのE-Coreをなるべく使い倒すという形で実装されているのが既に説明されている。実際により負荷の高い、例えばOffice Productivityでは早いタイミングでThreadがP-Coreに移行され、こちらを使い切る形で動作する、とされている(Photo07)。これを実現するための技術として説明されているのがこちら(Photo08)である。