初日の基調講演では比較的さらっと流された観のあるHaswellだが、続くTech InsideとかTechnical Sessionではかなりみっちりと内部構造についての紹介があった。というわけで、こちらの内容をお届けしたいと思う。
Microarchitecture
HaswellはIntelのTich/Tochモデルで言うところのTochに相当する製品で、プロセスをIvy Bridgeと同じ22nmに据え置いたまま、新Microarchitectureを搭載したものとなる(Photo01)。
|
Photo01: ちなみにこれに続くものとしては、Haswellと同じMicroarchitectureを搭載しつつ14nm Processを利用するBroadwellが2014年に登場(これが次のTich)、2015年には同じ14nm Processを使いつつ新Microarchitectureを搭載した(これが次のTock)Skylakeが予定されている。 |
さてそのHaswellのMicroarchitectureであるが、大きな変更はOut-of-Order部とBranch Prediction、Buffer/L1 D-Cacheといった辺りに集中することになった(Photo02)。一番目を引くのはOut-of-OrderのDispatchが従来の6ポートから8ポートに変更になったことで、遂に同時8命令同時処理という領域に達したことだ。ただPhoto02にもあるように、パイプライン段数は変わらないし、L1/L2のLatencyも変わらず、Branch PredictionのMiss Latencyも変わらないというあたりは、なかなか興味深い。まずBufferについて説明すれば、様々なBufferがHaswell世代で強化されていることが判る。ただ、後述するExecution Unitの増加の割りにInteger/FPのRegister Fileの数が増えていないのが興味深いところだ。
|
Photo02: TLBとキャッシュミスの予測を行うとか、複数のキャッシュミスを並行して扱うことでLatencyを遮蔽するとか色々怖いことが書いてあるが、具体的な説明は残念ながら無し。また分岐予測も"Improves performance and saved wasted work"とあるが、これも詳細の説明は無いままである。 |
|
Photo03: 遂にOut-of-orderのWindowは192となり、200近いμOpが常時In-Flightにあることになる。おまけにLoad/Storeもそれぞれ72/42に増えており、ここからするとIn-Order部の処理性能は既にSandy Bridge世代のものでも十分で、これに見合うようにOut-of-Order部を強化した、という感じが強い。 |
さてそのExecution Unit、Photo04の通り新たにPort 6とPort 7が追加されている。Port 6はInteger ALU/ShiftとBranchに割り当てられており、これでBranchの処理はPort 0とPort 6の2つに存在することになる。勿論これは同時に両方動くというよりも、ALUの利用頻度が高いケースでも分岐予測が確実に行えるように2つにしたという気がする。だったら特定のポートをBranchのみにすれば? という考え方もあるが、Sandy Bridge以降に搭載されたμOp Decoded CacheがHitしている間はそのポートが有効活用されないわけで、結局バランスを考えてこういう形になったと思われる。これにより、ついにALUが4ポートになった訳で、これはコンサバティブなアプリケーションの性能改善に効果的と思われる。一方のPort 7、こちらはPort 2&3でどちらもLoadを掛ける場合にStore Addressが後送りになるというか、Store Addessをやっている時にはLoadが1ポートしか有効にならないことへの対策と思われる。これはSandy Bridge世代に対しての改善ということになるだろう。
|
Photo04: ちなみにPort 0/1/5/6のALUはSimple ALIUで、これとは別にComplex ALU(Slow ALU)がPort 0にのみ実装されている。 |
しかしここまできて、ついに実行ユニットの重厚さがAMDのK7～K10世代を上回ったという形になるわけで、いち早く見切りをつけてBulldozer方向に向かったAMDとの対比がちょっと面白い。またAVX2関連でFMA(Fused Multiplay and Add)関係命令がPort 0/1に実装されているが、これは後述する。
次の変更点はCache周りである(Photo05)。先に述べたとおりCacheの構成やLatencyそのものはSandy Bridge世代と違いはないが、Bandwidthはざっくり倍になっている。これはAVX2命令が従来の2倍のデータを同時に処理できるようになったことに対応したもので、遂にデータ帯域は64Bytes/cycle(Load)+32Bytes/cycle(Store)に達している。このLoad/Store性能の大きさはかなりのもので、しかもLatencyが変わらないあたりは純粋にバスの本数そのものを倍増させていると思われる。よくこれだけのものが収まったな、というのが率直な印象である。またL2 TLBの大容量化及び2M Pageのサポートの追加は、64bit OSの普及が進んでより多くのPageを利用するケースやLarge Pageの利用頻度が上がったためと想像される。
|
Photo05: 64Bytes/cycleのL1は、ここには明記されていないがData L1のみでInstruction L1は16Bytes/cycleのままと想像される。というのは、DecodeというかFetchの帯域が16Bytes/cycleのままだからで、ここの帯域を64Bytes/cycleにしてもメリットが皆無だからだ。 |
ちなみにここまでやっても、性能の向上は対Sandy Bridge比でそれほど大きくはない。会場での説明によれば、絶対性能で20～25%、同一周波数の場合で10%前後という話であった。絶対性能というのは動作周波数の向上も含むという話であるが、注意してほしいのは今回Haswellの話はMobileのSkewに限られており、つまりTDPが15Wとかの範囲での性能改善である。後述するようにHaswellでは消費電力の改善も多く施されており、同じTDPならばIvy Bridgeなどと比べてもより動作周波数を(Turbo Boostで)引き上げやすい。同じ話がDesktop向けSkewでは通用しにくいのは、動作周波数をあげてゆくと急速に発熱が増えるからで、例えば65WというTDP枠の範囲でIvy BridgeとHaswellでどれだけ動作周波数の差が出るのか、現時点では未知数である。
