目からウロコのPentium4再考(≠最高)





日曜日は起きたらとんでもない時刻だった。 テレホーダイで夜更かししたのが効いたらしい。

昨日Webで見た後藤弘茂氏のWeekly海外ニュース 「0.13μm版Pentium 4にもHyper-Threadingテクノロジを搭載!?」 と言う記事は久々に目からウロコの記事だった。 こんなのが続々とタダで読めるから、つい夜更かししてしまうんだよな〜。 今日の内容にも直接関係するので、お暇な方は是非読んでみていただきたい。 タメになること請け合いである。

それにしても、この人の記事の 早さ・正確さ・洞察力には(プロのライターだからとはいえ)いつも驚かされる。 プロのライターには格というものがあるが、この人の記事は たるさん一押しの逸品が多い。ほとんどの記事が、いわゆる「当たり」なのだ。

金を取って情報を売っている雑誌でさえ、誤りが多いのに、 impressサイトの人寄せのためとはいえ、 質の高い情報をタダで読める事こそIT時代の恩恵であろう。 記事のレベルが低い雑誌には爪の垢でも煎じて飲ませたいくらいである。 (表紙に最新パーツの写真が載っているパソコン雑誌はまだいい方。 表紙におね〜ちゃんの写真が載っているパソコン誌系は特にひどい。)

さて、というわけでCrusoeの話題は少し脇に置いておく。 今回は次期Pentium4の話題とし、さっそく本題に入ろう。

以前UPしたPentium4のトレースキャッシュに対する意見で、 Pentium4にトレースキャッシュ+ハイパーパイプラインが採用された理由を 考察し、またPentium4のマルチスレッド対応について述べた。 それらをまとめると下記の通りになる。

まとめ
1.Pentium4ではトレースキャッシュ方式よりも、 通常型キャッシュ方式とした方が性能が高いと考えられる。

2.それでもあえてトレースキャッシュを採用したのは、 熱の問題を回避するためと思われる。

3.Pentium4をマルチスレッド対応化すると、スレッド数が少ない内は 通常キャッシュが有利だが、スレッド数が増えるに従って差が少なくなる。

4.投機的マルチスレッド対応の場合は立場が逆転し、 トレースキャッシュ方式が俄然有利。


そこで、上記の後藤弘茂氏の記事なのである。 Penitum4がはじめからHyper-Threadingテクノロジ搭載を 目指して設計されていたとは! 目からウロコとはまさにこのこと。 今まで心の中でモヤモヤとしていたものが一気に吹っ飛ぶ爽快感である。

なぜかって?
それは、Pentium4で性能低下の愚を犯してまで、なぜトレースキャッシュ+ ハイパーパイプライン構造にこだわったのか、すべての疑問が氷解するからだ。

上記のまとめを読むとおわかりいただけると思うが、 NetBurstアーキテクチャはシングルスレッドでは 通常のアーキテクチャよりも性能が悪い、 と言うのがたるさんの結論であった。 そして、マルチスレッド対応では状況が変わり、 マルチスレッド対応度が上がれば上がるほど、 通常アーキテクチャより性能面でメリットがあるという結論だったのだ。

現行のPentium4はマルチスレッド非対応だから、このまとめからは Pentium4がNetBurstアーキテクチャを採用する理由は説明しにくかった。 というわけで、たるさんは性能面からこれを説明する事をあきらめ、 熱の問題を取り上げて説明を試みたのである。

しかしである。もし、NetBurstアーキテクチャの設計者が、はじめから Hyper-Threadingテクノロジ搭載を目指して設計していたならば、 (たるさんのように熱の問題を理由にするまでもなく) 当然トレースキャッシュ方式を採用するだろう。 こちらの方が最終的には性能が高くなるからだ。

また、説明しにくい事はもう一つあった。 それは、Hyper-Threadingテクノロジ技術導入に伴う ダイサイズに関する記事に関してである。

ある記事でHyper-Threadingテクノロジ技術を搭載しても、 ダイサイズが5〜10%しか増えないという事が書かれていた。 これも実に奇妙な話であった。 事実、以前UPした マルチスレッド化で漁夫の利の予感 という記事で、たるさん自身はマルチスレッド対応化の難易度を、 「実行ユニット数を変えなくても中程度の改変、変更するなら非常に大きい。」 と書いた記憶がある。 マルチスレッド機能搭載のためのダイ改変はそんなに生易しいものではないハズだ。

しかしこれも、はじめからHyper-Threadingテクノロジ搭載を目指して設計されていた と考えると、当然、簡単な改造で対応できるわけで、 (というか、最初の設計通りに戻すだけ) ダイサイズが5〜10%しか増えないという話も納得がゆくのである。

やはり、プロのライターと一介のアマチュア・たるさんには 越えがたい洞察力の差があるんだな〜と、感心させられたワケだ。 と、感心してばかりもいられないので、たる流のHyper-Threadingテクノロジ に関する話題を一つ。

Hyper-Threadingテクノロジ技術の説明では、よく下記のような説明が見られる。 本屋で立ち読みを敢行するに、パソコン雑誌の説明はすべてこのように表現されているようだ。しかし、本当だろうか?

この雑誌でよく見られる図についてもう一度考えてみよう。 この図は下記のような内容を説明しているものと考えられる。

まず、条件は下記の通りである。
・下記のレッド、ブルー、グリーンの3つのスレッドがあり、 それぞれ7つの命令から構成されていたとする。
・命令処理は、命令1から数字順に行われるとする。
・各命令は実行ユニット内で、すべて1サイクルで実行できるとする。
・各スレッドは命令の依存関係から下記の表の通りに並列処理できるとする。
・スーパースカラの実行ユニットは3つであるとする。
・処理時間は実行ユニットの時間のみで、トレースキャッシュからの読み込み等の時間は計算に入れない。

スレッド・レッドの並列実行状態
実行ユニット1 命令6 命令4
実行ユニット2 命令5 命令2 命令1
実行ユニット3 命令7 命令3

スレッド・ブルーの並列実行状態
実行ユニット1 命令7 命令3
実行ユニット2 命令5 命令2
実行ユニット3 命令6 命令4 命令1

スレッド・グリーンの並列実行状態
実行ユニット1 命令4 命令3 命令1
実行ユニット2 命令7 命令5
実行ユニット3 命令6 命令2

ここで、シングルパイプラインCPU、スーパースカラ、 マルチスレッド対応スーパースカラの処理時間を考えてみよう。

シングルパイプラインCPUでは、それぞれの処理に7サイクル必要であるから、 3つのスレッドを処理する時間は21サイクルである。

スーパースカラCPUでは、命令の並列処理により 各スレッドを5サイクルで処理できる。 従って、3つのスレッドを処理する時間は15サイクルである。

では、Hyper-Threadingテクノロジ技術では何サイクルなのであろうか?

実行ユニット1 命令7 命令6 命令4 命令4 命令3 命令3 命令1
実行ユニット2 命令7 命令5 命令5 命令5 命令2 命令2 命令1
実行ユニット3 命令7 命令6 命令6 命令3 命令4 命令2 命令1


最も効率良く命令をパイプラインに押し込むと、上図のように並列化できる。 この時、処理時間は7サイクルである。 だから、マルチスレッド処理により、通常のスーパースカラより 2倍以上の高速化が可能だと説明されるわけである。 これは、SMT技術の一般論の説明としては正しい。

しかし、次期Pentium4で採用されるHyper-Threadingテクノロジ技術の 説明(雑誌等によく載っている図だ。)としては、正しくないように思われるのである。

以前の記事で、マルチスレッド処理には粒度の荒いマルチスレッド処理と 粒度の細かいマルチスレッド処理があると書いた。 しかし、マルチスレッド処理の分類法はこれだけではない。 視点を変えると、別の区分があるのである。

IPCを高めるに当たっては、パイプラインのどこに注目して パイプラインの稼働率を上げるかという問題がある。

一つはパイプラインの時系列のバブルをなくす事で効率化する。 上記のスレッド・レッドの実行ユニット1を見ていただきたい。 1,2,5サイクル目には処理能力がありながらユニットが遊んでいる。 これを埋める事ができればIPCはアップする。 時系列の最適化である。

もう一つは実行ユニットのハードウエア・リソースの 利用率を高める事で効率化する。 同様にスレッド・レッドの1サイクル目にご注目いただきたい。 実行ユニット1と3が動いていない。 これを稼働させる事ができればIPCはアップする。 リソースの最適化である。

すぐにおわかりになるように、両者を同時に行おうとすると、 状況によっては実行ユニットのバッティングが発生する。 だから、両者を同時に計算して性能予測をするのは難しい。

そこで、たるさんが計算を行うにあたっては、ハードウエアリソースの 利用率向上のテクを無視して、時系列のパイプライン・バブル抑制法 について考えた。

だから、同じIPC向上といっても、上記の図では ハードウエアリソースがより効率的に使用された事による性能 向上であるのに対し、たるさんが以前報告したテクは キャッシュミスや分岐予測の失敗のペナルティーが減る事 による性能向上がメインである。 同じIPC向上といっても、理由が違うのだ。

では、両者の説明のどちらが正鵠を射ているのであろうか?(続く)