さて、それでは順に結果を見ていきたいと思う。
Sandra XII
SiSoftware
http://www.sisoftware.co.uk/
まずはArithmetic Benchmark(グラフ1)。原則としては全てのテストがMulti-Threadで実施されるので、SkullTrailのスコアがX38のほぼ倍になることは正しい。むしろ問題はDhrystone.NETの性能が全然出ない事であろう。もっとも.NET環境下ではMulti-Threadが動かない訳ではない。Whetstone.NETとか、グラフ2(Multi-Media Benchmark)をみるとこちらはきっちり倍の速度で動いているからだ。まぁこれらのテストは、ちゃんと2P構成が動作する、ということを検証できる以上の意味はない。
気になるのはメモリの性能である。まずグラフ3、4はCache/Memory AccessのLatencyだが、案の定Memory AccessになるとLatencyが爆発している。X38の方が実質CL4動作していることを勘案しても、やはりFB-DIMMを経由させることによるレイテンシは大きいと言わざるを得ないだろう。
では肝心の帯域は? というと、L1～L2に関してはMulti-Threadの効用でSkullTrailが爆速である(グラフ5)。ただこれだと64MB以上のスコアがさっぱり判らない。そこでこの64MB以上の結果、それとMemory Bandwidthの結果をまとめたのがグラフ6である。全てのテストで、X38がSkullTrailを圧倒している事が判る。このあたり、4チャンネルフルにFB-DIMMを装着出来ていればもう少し状況は変わったと思うのだが、今回の環境では如何ともしがたいところだ。
当然これはMulti-Core Efficiencyにも影響する。平均的な帯域はSkullTrailが優位(グラフ7)だが、LatencyはX38の方が少ない。これを仔細に見たのがグラフ8である。L1 to L1とか、L2も溢れてメモリアクセスが発生するケースでは、当然SkullTrailは遅くなる。L1に関してはDual Processorであり、しかもShared Busと言いながら間にMCHが入る構造である以上、Latencyは巨大にならざるを得ない。一方途中はというと、L2の効果がフルに生かせるから、無駄にSkullTrailが高い帯域を維持できることになる。セオリー通りの結果ではあるのだが、何となくこのテストにどこまでの意味があるのか? を考え直したくなる結果ではある。
