はじめに
Intel Panther Lakeの詳細が発表されましたので、記録に残します。
上記の記事を見てみました。
今回は、特に
- Caches & Compute Cluster Types
が気になりました。
Caches & Compute Cluster Types
Panther Lake では、Cache の階層が下図のようになっているようです。下図は、上記の記事から説明のために引用します。
- P-Core : 各コアに L2 Cache を持つ
- E-Core : ４つのコアで L2 Cache を共有
- L3 Cache : P-Core と 4つの塊の E-Core が共有する。Coherency agent がある
- LP E-Core : 4つのコアで L2 Cache を共有する。Coherency agent がある
ここまでは、今までと同じ。違うのは、
- Memory side cache
Memory side cache の中には、Home agent なるものがあり、これが Systemのコヒーレンスを保ちます。
上記の2つの Coherency Agent と Host agent がなんかやってくれている。
で、Memory side cache には、どんなデータが載るの？
に、それぞれのCacheの説明がありました。Memory Side Cache のスライドもありましたので、説明のために引用します。
- 8MB
- Reduced DRAM traffic and power
- Enhanced latency and bandwidth
- Caching for I/O engines
とあります。
下図に各キャッシュの関係が載っています。説明のために引用します。
この図から妄想すると、
ArmのL3 Cache と System Level Cache との比較
Grok 4 Fast Beta さんに聞いてみました。
Arm系SoCのL3 CacheとSystem Level Cache（SLC）の比較
Armアーキテクチャを採用したSoC（例: Qualcomm Snapdragon、MediaTek Dimensity、Apple A/Mシリーズ）では、キャッシュ階層が多様で、L3 CacheとSystem Level Cache（SLC）は主にDRAMアクセスを最適化するための共有キャッシュとして機能します。ただし、L3は主にCPUコア間での共有に特化しているのに対し、SLCはSoC全体（CPU + GPU + 周辺機器）でのデータ共有を目的としたシステムレベルのキャッシュです。多くのArm SoC（特にモバイル）では、伝統的なL3を省略し、SLCをL3相当として使用する設計が一般的です。これにより、メモリボトルネックを緩和し、電力効率を向上させています。
以下に、Arm系SoCのL3 CacheとSLCの主な違いをテーブルで比較します。例として、現代のフラッグシップSoC（Snapdragon 8 Gen 3、Dimensity 9300、Apple A17 Pro）を基にしています。IntelのPanther LakeにおけるMemory Side Cache（MSC、8MB）も参考として追加し、全体像を明確にします。
| 項目 | L3 Cache (Arm SoC) | System Level Cache (SLC, Arm SoC) | Memory Side Cache (MSC, Intel Panther Lake) |
|---|---|---|---|
| 位置 | CPUコア/クラスター近く（L2の後）。主にCPU内部の共有。 | L1/L2とDRAMの間。SoC全体（CPUクラスター + GPU + peripherals）で共有。 | メモリコントローラ近く（DRAM I/O途中）。CPU/GPU/NPU/IOエンジン間で共有。 |
| 共有範囲 | 主にCPUコア間（例: big.LITTLEクラスター内）。GPU共有は限定的。 | SoC全体（CPU + GPU + NPU + IPUなど）。UMA（Unified Memory Architecture）対応で効率的。 | SoC全体（CPU + GPU + NPU + メディアエンジン）。統一メモリファブリックで直接アクセス。 |
| ポリシー | InclusiveまたはNon-inclusive（実装依存）。データ重複可能。 | Exclusive（L1/L2と排他的、GPUとInclusive）。データ重複を避け、スペース効率が高い。キャッシュラインサイズ128B。 | Directory-based（スヌープ最適化）。Exclusive-likeで、DRAMトラフィックを削減。 |
| サイズ例 | Snapdragon 8 Gen 3: 12MB Dimensity 9300: 8MB Apple A17 Pro: なし（SLC使用） |
Apple M1: 8MB A17 Pro: 12MB Snapdragon/MediaTek: 4-8MB（configurable 128KB-8MB） |
8MB（全構成共通） |
| レイテンシ | 低（コア近く、~20-40 cycles）。 | 中（~200-220 ticks、L2 miss時）。SLC missでDRAMへ。 | 中（メモリ側、LLC連携で~30-50 cycles）。DRAMアクセスをバッファ。 |
| 主な利点 | CPU中心のワークロード（マルチスレッド）で高速。電力低減。 | 混合負荷（AI/グラフィックス）でDRAM帯域削減（最大50%）。電力効率向上、サイドチャネル攻撃のリスクも。 | メモリトラフィック削減（10-30%）。AI/ビデオ処理でレイテンシ低減、電力40%低減可能。 |
| 欠点 | GPU/IO共有が弱く、SoC全体のボトルネック残る。 | サイズが小さい場合、ヒット率低下。Exclusiveポリシーで管理複雑。 | サイズ固定（8MB）で大規模データセットに不向き。 |
| 使用例 | 高性能CPUクラスター（Cortex-X/Aシリーズ）。Android SoC中心。 | Apple M/Aシリーズ、Arm CMN-600/700インタコネクト。モバイル/エッジAI。 | Lunar Lake/Panther Lake（モバイルAI PC）。 |
詳細解説
- L3 Cacheの役割: Arm SoCでは、L3はCPUコアのL2キャッシュを補完し、頻繁にアクセスされるデータをコア間で共有します。例えば、Snapdragonでは12MBのL3がbig.LITTLE構成の効率を高めますが、GPUアクセスは間接的です。AppleのAシリーズではL3を明示的に使用せず、代わりにSLCをL3相当として統合しています。
- SLCの役割: Armのbig.LITTLEアーキテクチャで導入されたSLCは、システム全体のデータ共有を強化します。Exclusiveポリシーにより、L2からevictされたデータがSLCに移動し、重複を防ぎます。Apple MシリーズではGPUとの共有が強く、UMAでメモリプールを効率化（例: M1のSLC hitレイテンシ~220 ticks）。サイズはSoC設計で柔軟（最大8MB）で、DRAMアクセスを20-50%削減しますが、サイドチャネル攻撃の脆弱性も指摘されています。
- Intel MSCとの違い: ArmのSLCと似てシステム共有型ですが、MSCはメモリコントローラ直近に位置し、IOエンジン（IPUなど）との連携が強い点が特徴。両者ともDRAM前バッファですが、SLCのExclusiveポリシーはデータ管理を厳格化し、Arm SoCの電力効率（モバイル向け）に適しています。一方、MSCはIntelのチップレット設計（Foveros）で省スペース化を図り、Panther LakeではL3（18MB）と連携してMT性能50%向上を実現。Arm SLCはGPU中心のAppleでグラフィックス優位、MSCはNPU中心のAI優位です。
この比較は、Armのヘテロジニアス設計とIntelの統合型アプローチの違いを反映しています。将来的に、ArmのSLC-3（CMN S3対応）でさらにスケーラブルになる可能性が高いです。
おわりに
Arm系のSystem Level Cache は、大体10MB。Panther Lake の Memory Side Cache は、8MB。まー、同じぐらいなんでしょうかね。
CPUコアやI/Oがメモリにアクセスすると、それなりの時間がかかるので、Cache を設ける。。。そうしないと、CPUの性能が無駄になるから。。。そう、AIアクセラレータと同じ。
いくら計算機が速くなっても、データ供給が間に合わないと、無駄になる。。。なんだか。。。。
