バイナリより低レイヤな話 (プロセッサの心を読み解く) -...

バイナリより低レイヤな話

@hktechno

@hktechno

川田 裕貴 (かわたひろたか)● 筑波大学に4月から入院中 (元coins09-AC)

○ システム情報工学研究科

コンピュータサイエンス専攻○ 実時間組み込みアーキテクチャ研究室

● Open Design Computer Project○ IPA 未踏 2011 スーパーなんとか

● トプスなんとかっていう会社でバイト中○ LLVM-IR と最近戯れている

● PyCon JP 2014 プログラムチーム

Open Design Computer Project

http://open-arch.org/● mist32 という自作CPUを作っている

○ 32bit Out of Order RISC コア○ In-order 版もあるよ○ FPGA (DE2-115, DE3) 上で動く

● CPU マニアと一緒にやっている○ @cpu_labs

● 自分はソフトウェアを作っている○ gcc, binutils, newlib...○ 最近 xv6 OS が動いた (実機は微妙)

今日の忘れ物

低レイヤ

低レイヤ感の違い

● hktechno: 低レイヤ好きな人いなくて● ???: 低レイヤ？うちにもいるよ？

● hktechno: どんなことやってるんですか？● ???: ほら、C++ とか

低レイヤ 検索

低レイヤ 検索

低レイヤー入門

● http://www.slideshare.net/demuyan/ss-19333584

疑問

● C が使えたら低レイヤなのか● バイナリが喋れたら低レイヤなのか● 低レイヤとはなにか

低レイヤとは

システムソフトウェア

VM

OS kernel

アセンブラ

バイナリ

カーネル/VM 的低レイヤ

Eject

アプリケーション

最低レイヤはなにか

バイナリは、最低レイヤでしょうか？

バイナリが喋れればかっこいいか？

バイナリが喋れるだけで、満足していませんか

相手の心もわかっていないのに

低レイヤ

自作コンピューター感の違い

● hktechno: コンピューターを自作してます● ???: 最近自作しなくなったなー

● hktechno: えっ● ???: えっ

低レイヤとは システムソフトウェア

VM

OS kernel

アセンブラ

バイナリ

プロセッサ

本来の低レイヤ

低レイヤとは システムソフトウェア

VM

OS kernel

アセンブラ

バイナリ

プロセッサ

低レイヤ

低レイヤとは システムソフトウェア

VM

OS kernel

アセンブラ

バイナリ

プロセッサCPUマニアが考える低レイヤ

低レイヤを知るなら...

バイナリだけ出来てもプロセッサは口説けない

そうだ、低レイヤを極めよう

プロセッサの心を読み解く

# 前振りが長かった

プロセッサの違い

● Intel 第4世代 Core アーキテクチャ○ Haswell (tock), Broadwell (tick)

● Intel 第3世代 Core アーキテクチャ○ Sandy Bridge (tock), Ivy Bridge (tick)

違いは何ですか？

● AVX2● TSX (HTM)● ???

SandyBridge -> Haswell

誰も気にしてくれない進化

● 演算ポートが2つ追加○ Integer ALU + Branch○ AGU for stores

● Branch prediction unit の改良● Reservation station の拡張● Re-order buffer の拡張● Physical register file の拡張

そもそもなんだかわからない

プロセッサのブロック図を眺めてみる

わかってそうで、わかってない内部構造

● Execution Ports● Out of Order Execution● Branch prediction● x86 を中心に色々眺めてみる

明日から使えるムダ知識

基本的なパイプライン

● Instruction Fetch● Instruction Decode● Execution

○ Memory Access● Write Back

● Instruction Fetch● Instruction Buffer● Instruction Decode● Dispatch● Execution

MIST32 (In-order: MIST1032ISA)

IB

ここまでが、インオーダーの話

ここから、アウトオブオーダーの話

実行ポート4個 OoOな領域

2命令同時 Fetch Decode …(Super- Scalar)

Out of Order Execution

mov eax, [eax]xor ebx, ebxadd ebx, eaxinc ecxadd eax, ecx

Load (遅い)

↑の命令とは依存がない

↑の命令とは依存がない

Out of Order Execution

mov eax, [eax]xor ebx, ebxadd ebx, eaxinc ecxadd eax, ecx

Load (遅い)

↑の命令とは依存がない

↑の命令とは依存がない

12323

命令の順番を入れ替えても構わないしかも、開いてるポートに並列に実行できる

Out of Order Execution

非順序実行

● 実行できる命令から実行する

プロセッサがやらなければならないこと

1. 命令の依存関係を知る2. 命令をバッファする3. 実行できる命令から実行する4. どの命令が終わったかを知る5. 本来の順序でレジスタへコミットする

Out of Order Execution

● Out of Order○ Intel P6 から実装 (Pentium Pro)○ Intel Atom (Silvermont から実装)○ ARM Cortex-A9 から実装○ mist32

■ ただし Load/Store OoO は未実装

● In Order○ Intel Atom (初代 Bonnell)○ ARM Cortex-A7 以前

速くはなるが回路規模は大きくなる

更に深く進んでみる

Out of Order Execution

● Register Renaming○ 物理レジスタを仮想レジスタにリネームする○ 命令の依存をより少なくできる○ (アウトオブオーダー実行に必須ではないが...)

mov eax, [eax]inc eaxmov [eax], eaxmov eax, ebxmov eax, [eax]

同じ eax レジスタだが、依存はない

← 先に実行可能

Out of Order Execution

代表的な OoO の実装

● Reorder Buffer○ 命令のコミットを制御するバッファ○ 演算の結果は一度ここへ書かれる

● Reservation Station○ 命令の依存関係を待つところ

○ ソースレジスタが利用可能かを監視して、

実行可能であれば実行を開始する○ Unified な方式、実行ポートごとに持たせる方式

Reorder Buffer (の一例)

Reorder Buffer Stage 1. 割り当て

Writeback Stage

2. 結果の書き込み

Retire / Commit

Reorder Buffer

Register File

3. コミット

Reservation Station (の一例)

Reservation Station

命令1 SRC1 NG

SRC2 OK

命令2 NG NG

命令3 OK NG

命令4 OK OK

Reorder Buffer,Register File

Execution ステージへ

息抜きに、x86 のブロック図を眺めてみよう

http://www.tomshardware.com/reviews/athlon-processor,121-2.html

http://www.tomshardware.com/reviews/athlon-processor,121-2.html

http://www.thg.ru/cpu/20001120/print.html

uOPs (micro-OPs)

みんな知ってる？

カーネル/VM では説明不要

最近? の uOPs

● Micro-OPs Fusion○ Fused Micro-OP○ 一部 uOP をまとめてパイプラインに流す

■ uOP 帯域の削減

● Macro-OPs Fusion○ 複数の x86 命令をまとめる○ 例えば CMP + Jxx○ Macro-OP レベルの並列性を向上

■ 少ないデコーダで実現

Branch prediction

分岐予測

● ブランチは厄介○ taken / not taken は直前になるまでわからない○ ミスするとパイプラインをフラッシュしてやり直し

■ すごい大きなペナルティになる○ ブランチするかしないか、予測する必要がある

分岐予測以外のアイデア

● Condition-Code (ARM)○ AArch64 では消え去りました

Branch prediction

mov eax, [eax]cmp eax, 0je is_zero......is_zero:...

実行完了するまで 分岐するかわからない

Branch prediction

● 分岐予測がアツイ (らしい)○ 電力があまり食わない上に性能向上に直結する○ Intel の 3% ルール○ 最近もいろいろな変更がある (ただし企業秘密?)

● 基本的な分岐予測○ 分岐しない (or する) 方向で常に予測しておく

■ 486○ 前回分岐した結果を保存しておく○ ループを検出する○ ...

Branch prediction

● Bi-modal counter○ よく branch するループは strongly taken に○ ほとんど branch しない場合は stolongly not taken○ 一度だけならいつもと違う動作をしても予測できる

Branch prediction

● Loop detector○ n 回目で必ず分岐するなら、n を記憶しておく○ 過去 n 回の分岐パターンを記憶する

● Global branch predictor○ ある特定の分岐をそれぞれ記憶するのではなく、

すべての分岐のパターンを記憶しておく○ 周りの分岐命令との相関関係

最近のプロセッサは、ハイブリッド分岐予測器

● Bimodal + Loop detector + Global● どれか有効なものを使用する

最近の x86 のブロック図を眺めてみよう

ブロック図を読み解く

http://arstechnica.com/business/2010/09/intels-next-must-have-upgrade-a-look-at-sandy-bridge/

http://www.hardwaresecrets.com/printpage/Inside-the-Intel-Haswell-Microarchitecture/1777

最近の Intel のプロセッサ

● Zeroing Idioms○ xor eax, eax のような命令をゼロレジスタに、

リネームする

● uOP Cache○ uOp の変換をキャッシュする○ フロントエンドが眠ることができる○ Intel のデコーダはでかい

■ でかいデコーダを眠らせると電力効率アップ

● 実行ポートの増加○ ブランチユニット、AGU が増えた

最近の Intel プロセッサ

他にも...● Physical Register File

○ 物理レジスタファイルへ直接書き込む○ 待ち受け命令への ROB からのコピーを削減

● 分岐予測機のさらなる改良○ 詳細不明、エントリが増えてるなど

● ROB, RS のエントリの追加● Macro-Fusion の命令の追加

最近の Intel のプロセッサ

● デコードの隠蔽に力を入れているっぽい○ x86 のクソ命令セットが重い○ デコーダに負担がかかる

■ デコーダ回路もでかい + 電力食い○ いかにデコーダを回さないか

■ uOP Cache■ uOP レベルでの分岐予測

● なぜ、あんなに性能が出るのか○ 命令セットはクズなのに○ Intel すごすぎ

ただし、Intel に x86 以外を作らせると...

http://pc.watch.impress.co.jp/docs/column/kaigai/20130912_615261.html

http://pc.watch.impress.co.jp/docs/column/kaigai/20120214_511793.html

まとめ

● マイクロアーキテクチャの進化○ まだまだ続きそう○ だけど Intel の独壇場的な感じもする

● 世代・メーカーで結構違う○ Intel と AMD のポートのもたせ方の違いとか