----- セッションC1:最近のプロセッサ・アーキテクチャ技術 講師:中村 宏(東京大学) 会場規模:B会場(席数 約150人) 参加者数:約70人 ----- [講演内容] 現在開発されている最新のアーキテクチャ技術ではなく「最近の」プロセッサ・ アーキテクチャ技術についての講演 ・はじめに 汎用プロセッサでは,ハードウェア資源投入による高機能化の追求. 組み込みシステムでは,設計制約のもとでのシステム実現 両者の歩み寄りが必要となっており,お互いに知る必要があるためこの講演 を行なう ・プロセッサの性能 プロセッサの性能はCPU時間で計ることができ (CPU時間)=(プログラム中の命令数)×(CPI)×(サイクル時間) で表される. この講演では,命令セットアーキテクチャと命令実行制御機構によりプロセッ サ性能の向上を計ることをターゲットとする. ・命令実行制御機構:CPI削減技術 命令パイプライン処理:パイプライン化することによりCPI削減 →pipeline depthを深くすることはCPIはそのまま,クロック周波数が向上 する superscalar:命令を並列処理することによりCPI削減 ・ILPの限界 ILP(命令並列度)は ・資源制約:同時発行命令数,命令の種類に制約 データパスの制約.ハードウェア資源に依存 ・制御依存:分岐命令に代表される 前の命令が終了しないと次の命令がわからない ・データ依存:前後の命令でレジスタが衝突 前の命令がレジスタアクセスを終了しないと後続命令がレジスタをアク セスできない ・Memory Wall メモリアクセスレイテンシ増大・スループット不足 ・制御依存 分岐命令の分岐先が確定しないと後続命令が発行できない. →CPIが増大 最近のdeep piplineでは深刻な問題 解決方法として分岐予測 ・静的分岐予測 分岐命令毎に条件の成立・不成立を予め予測しておき後続命令を発行する 分岐確定後誤って実行した命令は破棄 ・動的分岐予測 過去の履歴を分岐命令毎に実行時に採取し,その履歴に基づき分岐成立・不 成立を予測 ・1bit予測 命令の番地の下位数ビットでアドレスされる小容量のtable 前回の分岐成否情報(1bit)を用いて予測 ・2bit予測 2bitカウンタで状態保存(強taken予測,弱taken予測,弱not taken予測, 強not taken予測) 2回続けて外れないと予測を変更しない ・分岐失敗の原因 2bitでは間に合わないという予測自体の誤り アドレステーブルの衝突 ・entry数が足りないのか? 4096 entryと無限entryで比較 →4096 entryで遜色ない結果 entry増よりも予測手法自体の改良が必要 ・グローバル履歴を用いた動的分岐予測 分岐命令間で相関がある場合がある →分岐命令固有のローカルな履歴でなくグローバルな履歴情報も用いて分岐予 測する ・correlation predictor (m,n) predictor:過去m回のグローバルな履歴を用いて,各分岐命令が持 つ2^m個のtableを選択.各テーブルではn-bit予測 欠点: サイズが大きくなる. テーブルのセットアップ時間大(テーブルを埋めるまで正確でないため) ・gshare 分岐命令のアドレスの一部とグローバル履歴のXORをとって2bit分岐予測テー ブルを参照 必要となるテーブル領域の割には高性能 ・IBM Power4 3つの16L-entry 1bit predictor(local predictor) global predictor:gshare方式 1bit selector:localかglobalのどちらの予測をとるか決める ・Alpha 21264 local:two-level predictor 分岐命令アドレス10bitで1024 entry 3bit予測 global:global履歴12bit,各entryは2bit予測 selector:分岐命令アドレス12bitで2bit選択器 ・分岐予測に関するコメント 投資可能なコスト(面積) vs 達成したい精度 のトレードオフ 高性能マイクロプロセッサ: 97%から98%の精度を狙う 面積はさほど問題ではない 周波数への影響: 予測のすべてを1ステージでする必要なし →組み込みではどうするのか検討が必要 静的分岐予測 sypported by コンパイラ プロファイルベースコンパイラにより分岐成立・不成立に関してのヒント を与える 組み込みシステムでは,検討の余地大 ・ILPの限界:データ依存 データ依存によりレジスタアクセスの制約 ・データ依存関係 RAW:後続命令のoperado readは,先行命令のoperand writeより後 WAR:後続命令のoperand writeは,先行命令のoperand readより後 WAW:後続命令のoperand writeは,先行命令のoperand writeより後 in-order issueだとRAWが通常は問題 out-of-order issue RAWによる性能低下を低減するために行なう→WAR,WAW発生 ・out-of-orderの利点 命令を発行できるものから行なうためストールが低減される. ・register renamingの必要性 WARを回避するためにregister renamingを行なう ・tomasuloのアルゴリズム 初期out-of-orderの例 本質は現在も同様 ・Tomasulo Loop Example 簡単なループプログラムを例にtomasuloアルゴリズムを説明. ・Tomasuloアルゴリズムまとめ Reservation stations レジスタを下層的に多くしてregister renamingを行なう WAR,WAWハザードによるstallを回避 CDB(Common Data Bus)を用いて結果と生産者IDを放送,生産者IDは連想 マッチ→自然なrenamingが行なわれる ・reorder buffer speculation:投機実行 precise interruption: 命令順で前の命令は全部終了,状態を更新 命令順で後の命令は状態を更新してはならない. →命令順を保証する必要がある reorder buffer: 実行命令をin-orderに同期させる機構 commitをin-orderに発行させることにより状態変更をin-orderに行なう ・reorder buffer付きのTomasuloアルゴリズム 簡単なループプログラムを例にreorder buffer付きのtomasuloアルゴリズム を説明. ・Explicit Register Renaming tomasuloアルゴリズムではCDBに結果を放送してしまうためcommitに問題が ある→Explicit Register Renamingが解決方法 schedulingとrenamingを分離できる ・Out-of-Order実行まとめ ハードウェアによる動的なscheduling reservation station reorder buffer:状態更新の安全性の確保 explicit register renaming:schedulingとrenamingを分離 実装コスト 各種テーブルを必要とする(面積) 毎サイクル連想比較を必要とする ・ILPはどれほどあるのか? 理想的には高いが現実的なsizeになったとたんILPは低くなる ・Thread Level Parallelism ILPの限界 →より広範囲から並列度抽出 ループレベル,スレッドレベル,プロセスレベル ・multithread方式 superscalarでは依存関係により1つの命令列では発行スロットに空きがあり 演算器を有効に利用できない →別の命令列を同時並行実行することにより有効利用 Fine-Grained:毎サイクルスレッドを切替え Coarse-Grained:まとまった単位でスレッドを切替え Simultaneous Multithreading:単一サイクルで複数のスレッドを実行 (講師の)私見では: threadレベルの並列度があるから命令レベルの並列度活用はそこそこでい いと言うのは誤り 簡単にできるほうから攻めるべき threadレベル並列度活用はコスト大 命令レベル並列度に限界が見える場合に有力 →ILP以上が必要な時に利用すべきでは? ・ILPの限界:Memory Wall データ依存の問題を更に深刻にしている プロセッサとメモリ性能向上比が拡大していることに起因 ・latency 隠蔽技術 non-blocking cache + scheduling cache miss時にも可能であれば後続命令を実行するnon-bloking cacheを用 い依存関係をみるschedulingを行なえばストールせずに実行可能. prefetching 将来必要と思われるデータを予めキャッシュへ持ってくる ・cacheの問題点 allocation/replacementがハードウェア制御なので挙動を予測し難い. line conflictなどで突然性能が落ちる ・Scratch-Pad Memory スループット: チップ内は高集積度により向上可能 チップ外はpin bottleneckなどで向上難,連続大容量転送なら向上可能 望ましいアーキテクチャ: 再利用性のあるデータを確実にチップ上メモリへ載せる.→コンパイラが 読み切れればキャッシュでなくメモリへ載せる 再利用性のないデータは大容量転送を利用してチップ外からチップ内メモ リへ転送→再利用性ないのでキャッシュを使うとキャッシュを汚してしま う. ・SCIMA Scratch-Pad Memoryの例としてSCIMAを挙げる 東大で開発したScratch-Pad Memoryのアーキテクチャ SCM(アドレス指定可能領域)とデータキャッシュの割合は動的に再変更可 能なアーキテクチャ ・組み込みシステムへの応用 命令レベル並列度の向上: 演算器の稼働率を向上させる工夫→アプリケーションに特化した構成 集積度向上を活用したハードウェア機構→ILPの限界があるために演算器 ではなく演算器の稼働率を向上させるテーブル・メモリへ投資 汎用マイクロプロセッサと組み込みシステムでは達成すべき目標性能に違い がある.→処理のスループット,リアルタイム性 割り込みの応答性とout-of-order実行の親和性→out-of-orderでは投機状態 により応答性悪化につながる 最悪実行時間の保証→投機などにより予測が難しい.キャッシュなどで決定 的な要素が下がる Dynamic scheduling vs static scheduling コンパイラなら遠くの命令間の並列性も抽出可能(ハードウェアだと window sizeに依存) ただし,コンパイラでは実行時に決定することは読めない→プロファイル ベースコンパイラによりヒントをもらう ・まとめ プロセッサアーキテクチャ技術 CPI低減 control hazard,data hazardの回避方法 performance/costのトレードオフ関係 ソフトウェア・コンパイラでもできることはある 対投資効果で決定する ----- [質疑応答] Q:マルチスレッドの場合,投機を行なわない方がいいのでは? A:予測を多段に行なうなどの措置をとり Q:組み込みでVLIWなどにいくべきか? A:並列性がどれだけ必要かによる.また,命令互換性も問題になってくるであ ろう.アプローチとしてスーパースカラではなくシンプルな方向で行なうアプ ローチがいい場合があると思われる. Q:プロセッサ1つで並列処理を行なうより,複数プロセッサで処理を並列に行 なう方がパフォーマンスが上がるのではないか? A:プロセッサ間コミュニケーションが問題となる.なければ,複数プロセッサ で処理を並列に行なう方が有利.この問題は対象アプリケーションによる. Q:OS,アプリなどをそれぞれ個別のプロセッサで行なうアプローチはいいので はないか? A:この場合もプロセッサ間のコミュニケーションが問題になるであろう.有利 に働くようであればそのアプローチもいいのではないか. Q:この講演での紹介技術をエンドユーザーが使いたい場合どうすればいいか? 手軽に利用できるような方法はないであろうか? A:DA屋さんにがんばって作っていただきたい.命令の制御論理を変える必要が あるので現行のプロセッサでエンドユーザーが直接利用できるようにするには 設計変更が必要となる. ----- [記録者自身の感想] 現在マイクロプロセッサで利用されている性能向上技術を紹介していただけて どのようなアーキテクチャが利用されているのかが整理できた. 汎用プロセッサに利用されている紹介技術を組み込みシステムへどのように応 用するかは設計者に託されているようだった.汎用プロセッサと組み込みシス テムの技術などについて両者とも歩み寄り知識を深める必要があることが感じ られた.