写真提供:マイナビニュース

写真拡大

●富士通の第12世代目プロセサ「SPARC64 XII」
横浜にて開催されたIEEE主催のプロセサ関係の国際会議「COOL Chips 20」において、富士通は第12世代目となるプロセサ「SPARC64 XII」を発表した。ポスト京のスーパーコンピュータ(スパコン)では、プロセサはARM v8アーキテクチャに変更することが発表されているが、ビジネスサーバではSPARCアーキテクチャを引き続き使っていくことを明らかにした形である。

このところ、SPARC64やポスト京プロセサの学会発表について富士通では、吉田利雄氏や清水俊幸氏が行うことが多かったが、今回は、丸山拓巳氏の久々の登場である。

SPARC64 XIIプロセサの発表で目を引くのは、12コアという点である。番号順でいうと直前となるSPARC64 XIfxは32個のプロセサコアと2個のアシスタントコアを搭載する34コアプロセサチップであったが、今回のSPARC64 XIIでは、ほぼ1/3の12コアに減ってしまっている。なお、ビジネス系プロセサとしては直前の世代であるSPARC64 X+は16コアであり、それと比べてもSPARC64 XIIはコア数が減っている。

しかし、次の設計思想のスライドに見られるように、SPARC64 XIIは高シングルスレッド性能と高スループットを追求したプロセサである。クロックは4.25GHz(高速モードでは4.35GHz)と4GHzを超える高速クロックで、コア数は減ったものの各コアが8スレッドを並列実行することでチップあたり417G命令/sのスループットを実現している。このスループットはSPARC64 X+の2倍近い。

少ないコア数で高いスループットを実現する仕組みは、まず、各コアがSMTで8スレッドを並列実行するアーキテクチャになったことである。そして、32MiBという大きなL3キャッシュも性能向上に効いている。

次の図のコア仕様の表をみて気が付くのは、整数と浮動小数点のレジスタファイルと演算器、そして1次データキャッシュが×2pipeと書かれている点である。つまり、1次命令キャッシュと命令のフェッチ系は1つであるが、実行資源は2倍になっており、SPARC64 XIIのコアは、SPARC64 X+のコアのほぼ2倍の大きさになっていると考えられる。そう考えると、SPARC64 XIIでは、16コアのX+から、X+相当では24コアに増えており、スループットが上がっていることに不思議はない。

SPARC64 X+からのマイクロアーキテクチャの拡張点は、実行パイプラインの数を倍増し、8スレッドのSMTとなった点である。実行資源が2倍で、スレッド数は4倍であるので、実行資源の使用がヘビーなアプリケーションでは資源制約となり4倍のスレッドがフルに動かないケースもあると思われるが、資源の利用が少ない使い方の場合はスレッド数に比例した性能が得られる場合もあるので、スレッド数4倍、実行資源量2倍という拡張が有利ということであろう。

そして、分岐予測のやり方の改善や各種のキューのサイズも増大させている。また、クロックを4GHz超に引き上げるためにパイプラインを刻んで、段数を増加させている。

コア以外の部分の変更では、キャッシュレベルを3階層とし、ラストレベルキャッシュとコアユニットをまとめたLCUを4個置くという構成となった。富士通は、ながらくL2キャッシュにこだわってきたが、SPARC64 XIIではL3キャッシュを置くことになり、標準的なキャッシュ階層となった。

●「MEZASI」という名が付けられたキャッシュプロトコルtitle=COOL Chips 20 - 富士通の12世代目となるSPARC64 XIIプロセサ
次の図は、ECCやパリティによるエラー検出と訂正を説明する図で、右側の図の黄緑の部分は1ビットエラーが起こっても訂正できる部分、灰色の部分は1ビットエラーが起こっても悪影響の出ない部分である。そして、黄色の部分は1ビットエラーを検出できるが、訂正はできないという部分である。ただし、ここでいう訂正はCPUチップのハードだけでは訂正できないという意味で、エラーの発生は検出されているので、OSと連携してリブートするなどを行なえば、リカバリできない故障はもっと少なくなる。

SPARC64は、ECCで訂正できないロジックのエラーでも、エラーが検出されると、仕掛中の命令をフラッシュ(取り消し)して、エラーが検出された命令までシングルステップ実行を行う。そして、それが成功すると、スーパースカラでの実行に復帰する。この機構の説明は毎回同じであり、SPARC64 Vからあまり変わっていないと思われる。

なお、シングルステップ実行を行うのは、チップ内部で動作する部分を少なくして、ノイズを減らし、前にエラーした命令が正しく実行され易くするためである。

SPARC64 XIIの各コアは2つの実行パイプラインを持っている。しかし、1次命令キャッシュとTLBは両方のパイプラインで共用している。この構成はデータベースアプリでは有効であるという。次の図の中の表は、実行スレッド数と資源割り当てを示したもので、2スレッドの場合は、各スレッドが1つのパイプラインを占有する形になる。それより実行スレッド数が多くなると、各スレッドが使用できる資源量は減っていくが、資源量が半分になっても性能は半減しないものもあり、全体のスループットとしては増加する。また、この表のような固定的な資源分割だけでなく、ダイナミックに共用されるので、さらに有利になるという。

SPARC64 XIIでは、3レベルのキャッシュ階層となり、4つのLCUとして実装されていることは、すでに説明したが、L2キャッシュのレイテンシはL3キャッシュのレイテンシの半部以下であり、L2キャッシュからコアには、2つのパイプラインそれぞれが、32バイト幅のバスで接続されている。また、L3キャッシュからは32バイト幅のバスで3つのコアそれぞれに接続されており、十分なバンド幅を確保している。

キャッシュプロトコルは富士通独自のもので、「MEZASI」という名前が付けられている。京コンピュータのネットワークは「Tofu」であり、どうも富士通のサーバ開発チームは、食いしん坊で、和食を好むようである。

また、L3キャッシュの未使用部分を(L2キャッシュを追い出されたデータを格納する)ビクティムキャッシュとして使用したり、I/Oが直接L3キャッシュにDMAで書き込む、L3キャッシュのアクセスと並行してメインメモリをアクセスするなど、きめ細かい改善を積み重ねている。

このSPARC64 XIIプロセサを使用して、「M12-2」というミッドレンジサーバと「M12-2S」というスケーラブルなハイエンドサーバを商品化している。この写真ではどちらも同じように見えるが、右のM12-2は2CPU 24コアだけの構成であるが、左のM12-2Sは筐体間の接続機構を持っており、最大32CPUまで拡張できるようになっている。

M12-2Sは、2CPUと2クロスバをビルディングブロックとして、最大16ビルディングブロック、32CPU、378コアまで拡張できるようになっている。筐体内部のCPU間の接続は25Gbpsであるが、筐体間の接続は、ある程度、長くなるので、14.5/14Gbpsとなっている。

SPARC M12サーバではCPUの冷却に、新開発の相変化型のクーリングプレートを使っている。CPUに取り付けられるクーリングプレートには液相の冷媒が供給され、CPUの熱で蒸発して気相になり、筐体後部に置かれた大きなラジエータに運ばれる。冷媒は、ラジエータで冷却されて液相に戻り、ポンプでクーリングプレートに送られるという循環を行う。

相変化を使い、気化熱を利用する冷却であるので、蒸発を使わない液相だけの冷却に比べて2倍の冷却性能が得られるとのことである。

次の表に示すのは標準ベンチマークの性能だが、1CPUでのSPARC64 XIIサーバのSPECint_rate2006は956だ。一方、他社のXeon E7-8893 v4 3.2GHzクロックを4チップ使う16コアのCISCOのサーバが994、Xeon Phi 7250 1.4GHzクロック、68コアのDellのサーバが1020と言ったところ。2チップでは、SPARC64 XIIは1910だが、Xeon E5-2699A v4 2チップのLenovoのサーバが1890で、まあ、1チップ、2チップではIntelのXeonやXeon Phiと比べて同程度の性能を出している。

Javaアプリの性能を測るSPECjbb2015のCriticalでは、2チップのSPARC64 XIIで63,354jOPSとなっているが、例えば、24コアのXeon E7-8894 v4を4チップ使うHPEのProliant DL580 Gen9が86,878。半分の2チップで7割強の性能なので、測定値はないものの、同じ4CPUなら勝てそうな感じをうける。ということで、ビジネス向けのベンチマークで、Intelの最新のXeonやXeon Phiと互角に戦えるCPUになっているといえる。

次の図のSPARC64 XIIのコア性能は、SPARC64 X+コアのシングルスレッド性能を1.0としたとき、2.3〜2.9倍で、チップ単位で比較すると1.8倍〜2.2倍になっている。この性能向上は8Way SMT化、クロックの向上、さらにマイクロアーキテクチャの改善で達成されている。

そして、富士通は新しい時代のニーズに応えるため、継続してSPARC64シリーズのプロセサを開発して行くと結んだ。

しかし、性能の評価は、これまでのビジネスアプリであるJavaやOLTPであり、ビッグデータやニューラルネットなどの新時代のアプリケーションの性能評価は含まれていない点が気になった。富士通は、ニューラルネット用のアクセラレータチップを開発しており、これでカバーするということであるのかも知れないが、IntelやIBMはアクセラレータの開発と並行してCPUのニューラルネット性能の改善も行っており、ビジネスサーバ用でも従来のアプリだけでの性能評価では方向がずれてしまう恐れがあるのではないだろうか。

(Hisa Ando)