Benchmarkその1: 外部グラフィック
ではまずはCPU性能を中心に、比較を行なってゆきたいと思う。こちらのテストでは、Radeon HD 7970を使って(=内蔵グラフィックを使わずに)評価を行なった。ちなみにグラフ中の表記は、
Ivy Bridge : Core i7-3770K+ASUSTeK P8Z77V-PRO
Haswell : Core i7-4770K+Intel DZ87KLT-75K
となっている。
Sandra 2013 SP3a Engineer Edition(グラフ1~23)
SiSoftware
http://www.sisoftware.co.uk/
前回Kabiniのベンチマークで、Sandra 2013だとどうもJavaが動かないと説明したが、今回Haswellで実行すると無条件ブルースクリーンだった。実はうっかりSandra 2013もSP3aまでバージョンアップされていることに気がつかなかったのが理由で、こちらにバージョンアップしたらHaswellでもブルースクリーンは出なくなったし、Javaもちゃんと動作するようになった。ちなみにこのSP3aから、新たにFinancial Analysisが追加になったほか、Cryptgraphyの内容が少し変わっている。
さて、まずはいつものSandraである。まずグラフ1がDhrystone、グラフ2がWhetstoneであるが、どちらについてもNative Codeで実行するとむしろIvy Bridgeの方が高速、という面白い結果になっている。ただ.NETではDrystoneで同等だし、JavaではむしろHaswellの方が高速という、ちょっと面白い結果になっている。実は最初この結果を見たとき、動作周波数が間違っている(Haswellが定格より遅い or Ivy Bridgeが定格より速い)を疑ったのだが、続く結果をみてそういうわけではないことを納得した次第である。
次のProcessor Multimediaは(グラフ3~5)でNativeが異様に伸びている理由は、AVX2のサポートに起因する。こちらで以前触れたとおりAVX2はAVXの倍の帯域をサポートするが、Integerはともかく、Float/Doubleできっちり倍にならないのは、実際のキャッシュ帯域か演算器のどちらかにボトルネックがあるためと思われる。.NET/Javaでは若干ながらHaswellがIvy Bridgeを上回る結果を出しているあたり、性能の上がり方はどんなプログラムを動かすかに結構敏感に反応しそうだ。
グラフ6~8はCryptographyの結果である。今回からAES128とAES256、SHA1/SHA2-256/SHA2-512の組み合わせ、という形で示されるようになった。傾向としては3つとも同じで、AESのEncryption/Decryptionは微妙にHaswellが、SHAに関してはIvy Bridgeが微妙に高速、という結果になっているのが判る。
グラフ9・10がFinancial Analysisの結果である。ここではブラック・ショールズ方程式、2項分布、モンテカルロ法の3種類の方式で金融商品の価格付けを行なっている。要するに3つとも確率分布の計算と考えれば良い。グラフ9がFloat、グラフ10がDoubleでの計算だが、結果はいずれもIvy Bridgeが若干だが高速という結果である。
次からはメモリアクセス関連。まずグラフ11・12がMulti-Core Efficiencyである。グラフ11がOverallだが、トータルとしてHaswellの方が微妙に遅く、ややLatencyが多いという結果になっている。詳細がグラフ12だが、全般的に値は似通っているし、4×1MB以上の範囲ではHaswellの方がやや良い。あるいは4×4KBでもHaswellが上回っている。ただ1×64とかではIvy Bridgeが逆転しているし、4×256KBでは大差がついており、このあたりでトータルのスコアが決まった感じはある。L1の範囲では検討しているし、L3/Memory AccessでもHaswellが優勢だが、L2の範囲では逆転するという印象だ。
ではメモリアクセスそのものは? ということで、まずはBandwidthがグラフ13。こちらをみると、64KB以下ではHaswellの圧勝である。これの理由は簡単で、AVX2の実装に伴いLoad/Storeユニットの帯域が倍増しており、これがそのまま反映されている形だ。その一方、L2の範囲ではIvy Bridgeがやや高速になっている。
グラフ14はメモリアクセスの帯域で、StreamのIntとFloat、及びグラフ13の64MB~1GBの平均値の3つをまとめたものだが、64MB~1GBではHaswellがやや上回っているのに対し、StreamではIvy Bridgeの方が高速というあたりも、「どんなプログラムを実行するか」で性能が変わることを示している。要するに単純に「Ivy BridgeよりもIPCが向上した」訳ではなく、「Ivy BridgeまでとHaswellでは最適化の方法が変わっており、場合によってはやや性能が下がる」という傾向にあることを示していると思う。
グラフ15~21まではCache/MemoryのAccess Latencyの比較である。このテストも少しづつ進化しており、まず命令アクセス(Instruction/Code)とデータアクセス(Global Data)の2種類についてSequential/Full-Random/In-Page Randomの3種類でのアクセス結果を示してくれる。グラフ15がOverallであるが、こちらはLatencyなので値が大きいほど遅いということになる。結果はもう見て判る通りで、Instructio/CodeのIn-Page Randomを除くほぼすべてのケースでHaswellの方がLatencyが大きいとなっている。以下順に詳細を示すが、まずInstruction/Codeでは全般的にL3(LLC)までの範囲ではHaswellの方が少ないLatencyである。ところがメモリアクセスではIvy Bridgeの方が全般的に低Latencyで、これが平均値を決めた感じだ。In-Page RandomのみでHaswellが高速だったのはグラフ18で判る通り、なぜかこれのみMemory Accessの範囲でもHaswellの方が低Latencyなのが効いている。ただ、「なぜこちらが低Latencyなのか」はこれだけでは判らない。
一方Data Accessでは首尾一貫してHaswellの方がLLC~Memory Accessの範囲でLatencyが多く、これがそのまま結果に繋がっている形だ。
最後はPCI Expressのアクセス性能を測定するため、GPU Memory BandwidthとVideo Memory Bandwidthを実施、ここからSystem to Device(PC→GPU)(グラフ22)とDevice to System(GPU→PC)(グラフ23)の結果をまとめたものだ。こちらは非常に面白い結果である。まずグラフ22を見ると、OpenCLのみIvy Bridgeが高速だが、その他はHaswellの方が高速である。ただ全体としては差は非常に僅かだ。ところがグラフ23では、すべてのAPIでIvy BridgeがHaswellの倍の性能になっているというか、数字を見ればHaswellがIvy Bridgeの半分しか帯域が出ないというほうが正確だろう。ちょっと意外だが、これはGPGPU的な使い方をする場合にちょっとボトルネックになりそうだ。