電話 03-6410-6070、FAX 03-6410-6073 電子メール ｉｎｆｏ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ / ｓｕｐｐｏｒｔ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ (アドレスは半角に変更して利用)
HPC-ProServer DPeR210 II
第２世代Coreプロセッサ (Sandy Bridge)
Xeon E3-1200番台プロセッサを搭載した1-Socket 1U サーバ
DDR3 133MHzメモリ採用し21GB/sの帯域幅を実現
ECC付きメモリを最大32GBまでサポート
2TBディスクを2基搭載でき最大4TBのディスク容量を実現
大口径低回転ファンを採用し静粛性に配慮
RedHat6.1を標準搭載、用途によってCentOS 5.6オプション搭載
Intel Composer XE 2011開発環境セットアップサービス実施
ネットワーク設定、ジョブスケジューラ設定、ファイサーバ接続設定サービス有
3年間の翌営業日オンサイトサポートを実施
３年間のHPC技術支援を無償で実施
はじめに
Wine2kのベンチマークテストを通じて理解する
第２世代Coreプロセッサ Sandy Bridge を搭載した
HPC-ProServer DPeR210 IIの基本性能
Wine2kの公式ページにおいてSandy Bridgeのベンチマークテスト結果が公開されていました。その結果を見ると、Wine2kのシリアル処理性能はSandy Bridgeに実装されているAVX命令セットによって大幅に高速化されていました。しかし残念なことにWine2kの並列処理性能は高速化していませんてした。どこかにボトルネックがあるようです。その原因を特定するためにはさらに踏み込んだテストが必要です。
ところが幸いなことに、一般のお客様からWine2kによるSandy Bridgeの並列処理についての踏み込んだベンチマークテスト結果が寄せられました。その結果を調べたところ、Wine2kによるSandy Bridgeの並列処理で発生しているボトルネックの原因を推定できました。並列性能が出なかった原因は、メモリ性能不足とノード内通信性能不足が複合していたからのようです。原因が推定できたことで、Sandy Bridgeを採用したシステム設計の方向性が見えてきました。
このページではこれら２例のベンチマークテスト結果を元にして、Wine2k用の計算機システムを構築する上でのSandy Bridgeと開発環境の課題を探り将来を展望します。
1) Wine2k公式ベンチマークで
Sandy Bridge Core i7のAVX命令セットが
高い性能を発揮していた
Wine2kの公式ページから引用したベンチマーク結果
Wine2kの公式ページにおいて「第２世代Coreプロセッサ・ファミリ (開発コード名Sandy Bridge)」のCore i7-2600 3.50GHzを使用した、Wine2kのベンチマークテスト結果が公開されていました。
次の表はそのページから旧Nehalemと新Sandy BridgeによるWine2kのベンチマーク結果を引用したものです。両者を比較するとAVX命令の効果を確認できます。また、Sandy Bridgeでの並列処理の限界を確認することができます。
| プロセッサ / 開発環境 | 並列環境 | CPU数 | 並列度 | 経過時間 (秒) |
直前の 処理からの 高速化率 |
| 旧 Nehalem, Core i7-980x 3.30GHz, 128bit SSE対応 Memory B/W 25GB/s Intel Fortran 11 + Intel MKL |
MKL | 1 | 1 | 65 | - |
| 新 Sandy Bridge, Core i7-2600 3.40GHz, 256bit AVX対応 Memory B/W 21GB/s Intel Composer XE 2011 4.191 (AVX対応) Intel MKL (AVX対応) |
MKL | 1 | 1 | 37 | - |
| 2 | 26 | 30 % | |||
| 4 | 22 | 15 % |
※ Wine2kの公式ページで公開されていたベンチマークテスト結果を引用
最初に、旧Nehalemと新Sandy Bridgeのシリアル処理性能を比較してAVX命令の効果を確認します。Nehalemのシリアル処理の経過時間は６５秒、Sandy Bridgeのシリアル処理の経過時間は３７秒であり、高速化率は４３パーセントでした。Sandy Bridgeの単体コア性能がAVX命令によって向上し、実際のアプリケーションを高速化させていることが確認できました。
次に、Sandy Bridgeのシリアル性能と並列処理性能を比較します。Sandy Bridgeのシリアル処理の経過時間は３７秒、２並列処理の経過時間は２６秒であり、高速化率は３０パーセントでした。この３０パーセントという高速化率は２並列としては低い値です。Sandy Bridgeは２並列からボトルネックが発生しているということです。
そこでさらに、２並列処理と４並列処理の経過時間を比較します。Sandy Bridgeの２並列処理の経過時間は２６秒、４並列処理の経過時間は２２秒であり、高速化率は１５パーセントでした。Sandy Bridgeは４並列で完全に頭打ちになっています。
この頭打ちの原因を推定すると、メモリボトルネックかあるいはシステム内の通信ボトルネックが発生しているためだと思われます。しかし残念なことに、このベンチマークテストだけでは原因を絞り込むことはできません。さらに踏み込んだベンチマークテストが必要です。
注意点)
ここでのひとつ注意していただきたい点は、ここで発生したボトルネックは、AVX命令セットが真の性能を発揮した結果としてメモリボトルネックか、あるいはシステム内の通信ボトルネックが発生したと思われることです。もし、AVX命令セットが真の性能を発揮していなければ軽いボトルネックしか発生しなかっただろうということです。ですから発生したボトルネックによって直ちにSandy Bridgeに深刻な問題があるとは判断できません。しかし他方で、AVX命令セットを活かすためにはメモリシステムやノード内通信システムの高性能化が求められていることも確かなことです。
2) お客様から寄せられたWine2kベンチマークテスト結果からも
Sandy BridgeでAVXの性能が発揮されていることを再確認。
Sandy Bridgeの並列性能が低い原因を調査。
MKLとMPIによる並列処理の負荷の違いの調査と、
Sandy BridgeとNehalemによるデータ転送性能の違いを調査、
Sandy Bridgeの並列処理のボトルネックを特定
ベンチマークの概要
Wine2k公式ベンチマークとは別に一般のお客様からも、新Sandy Bridge Xeon E3-1280 3.50GHz 4Core 1CPU機と、旧Nehalem Xeon X5670 2.93GHz 6Core 2CPU機による、Wine2kのベンチマークテスト結果が寄せられました。
このベンチマークテストでは、Sandy Bridgeの並列処理の特性を明らかにするため、次のようなテストがシリーズで実施されていました。
・Sandy BridgeとNehalemでのシリアル処理
・Sandy BridgeでのMKLによるマルチスレド並列処理 (ノード内並列)
・Sandy BridgeでのMPIによるマルチプロセス並列処理 (ノード内並列)
・Nehalem Xeon 2CPUでのMKLによるマルチスレッド並列処理 (ノード内並列)
・Nehalem Xeon 2CPUでのMPIによるマルチプロセス並列処理 (ノード内並列)
・Nehalem Xeon 2CPU 4node I/Bクラスタでの
MPIによるネットワーク並列処理 (ノード内並列 + ノード外並列)
コンパイルについての注意点
なおこのベンチマークテストで使用されたWine2kのバイナリは、Nehalemで構築されたクラスタをターゲットにコンパイルされたものであるため、コンパイル時にAVXオプションを使用されていないそうです。そのため生成されたバイナリはSSE命令セットに対応したものであり、AVX命令セットには対応していません。AVX命令セットに対応しているのはインテルの数値演算ライブラリMKLのみです。
すなわちAVX命令を使用しているのはMKLのみだということです。
テストで使用された計算機環境
・アプリケーション
Wine2k 11.1
・開発環境
Intel Composer XE 2011.4.191 (AXV対応) (Wine2k公式コンパイラ)
Intel MKL (AVX対応)
Intel MPI 4.0.2
・コンパイル方法の特徴
NehalemとSandy Bridgeで共通のバイナリを使用
コンパイル時にAVXオプションを使用していない
コンパイラが生成したバイナリはSSE命令を使用している
AVX命令はIntel MKLのみが使用している
・計算機 A
(SandyBridge Xeon 1CPU 1node Server)
HPC-ProServer DPeR210II
CPU: Xeon E3-1280 3.5GHz、1CPU 4core
Memory: DDR3 1333MHz x 2ch 21GB/s
・計算機 B
(Nehalem Xeon 4node I/B Cluster)
HPC-ProServer DPeR610 4node
CPU: X5670 2.93GHz、2CPU 12core
Memory: DDR3 1333MHz x 3ch x 2cpu 64GB/s/sys
system Inter Connect: QDR InfiniBand
・ベンチマーク内容
mpi-benchmark (1.3GBくらいのメモリを使用するべチンマークテスト)
お客様から寄せられたベンチマーク結果
次の表は、一般のお客様から寄せられたSandy BridgeとNehalemによるWine2kの各並列処理ベンチマークテスト結果の一覧表です。
| 計算機 / メモリシステム / 開発環境・並列環境 | 並列環境 | ノード数 | CPU数 | 並列度 | 経過時間 (秒) |
直前の 処理からの 高速化率 |
| Sandy Bridge Xeon, X3-1280 x1 3.50GHz (AVX対応) DDR3 1333MHz x 2ch x 1 21GB/s/sys Intel Composer XE 2011.4.191(AVX対応) MKL (AVX対応) + Intel MPI |
MKL | 1 | 1 | 1 | 441 | - |
| 2 | 337 | 24 % | ||||
| 4 | 311 | 8 % | ||||
| MPI | 1 | 1 | 4 | 313 | - | |
| Nehalem Xeon, X5670 x2 2.93GHz (SSE対応) DDR3 1333MHz x 3ch x 2 64GB/s/sys Intel Composer XE 2011.4.191 MKL + Intel MPI + InfiniBand |
MKL | 1 | 2 | 1 | 860 | - |
| 2 | 566 | 34 % | ||||
| 4 | 409 | 28 % | ||||
| 6 | 378 | 8 % | ||||
| 12 | 363 | 4 % | ||||
| MPI | 1 | 2 | 12 | 194 | - | |
| MPI + I/B | 2 | 4 | 24 | 104 | 46 % | |
| 4 | 8 | 48 | 58 | 44 % |
Sandy BridgeとNehalemでのシリアル処理
最初に、新Sandy Bridge Xeon E3-1280 3.50GHzと旧Nehalem Xeon X5670 2.93GHzでのシリアル処理の性能を比較しAVX命令の効果を確認しました。Sandy Bridgeのシリアル処理の経過時間は４４１秒、Neahlemのシリアル処理の経過時間は８６０秒であり、高速化率は４８パーセントでした。
ただし、テストに用いた２台の計算機はクロック速度の差が大きいため結果の値を補正する必要があります。そこで、Nehalemのクロック速度を3.50GHzに補正すると経過時間は６９５秒になり、補正後の高速化率は３６パーセントでした。
この補正後の３６パーセントという不十分な高速化率から、Sandy Bridgeはシリアル処理でもボトルネックがあることがわかります。(なおこのテストでは、AVX命令はMKLから使用しています)
Sandy Bridgeのシリアル処理の経過時間 ４４１秒
Nehalem 2.93GHzのシリアル処理の経過時間 ８６０秒
Nehalem 3.5GHzに補正したシリアル処理の経過時間 ６９５秒
補正前の経過時間を使った高速化率 48%
補正後の経過時間を使った高速化率 36%
Sandy BridgeでのMKLによるマルチスレド並列処理 (ノード内並列)
次に、Sandy BridgeのMKLによるマルチスレッド並列処理での並列性能を並列度を変化させて比較しました。Sandy Bridgeのシリアル処理の経過時間は４４１秒、Sandy Bridgeの２並列の処理時間は３３７秒であり、高速化率は３４パーセントでした。Sandy Bridgeは２並列処理で頭打ちの兆候を示しています。
さらに、４並列処理を確認すると、Sandy Bridgeの４並列処理の経過時間は３１１秒であり、高速化率は８パーセントに下落していました。並列性能の向上は完全に頭打ちになっています。
Sandy Bridgeのシリアル処理の経過時間 ４４１秒
Sandy Bridgeの２並列処理の経過時間 ３３７秒 (１並列からの時間短縮率 34%)
Sandy Bridgeの４並列処理の経過時間 ３１１秒 (２並列からの時間短縮率 8%)
Sandy Bridgeは、数値演算ライブラリMKLによる並列処理では十分な性能が得られないことがわかりました。
またこれは、先に記載したWine2k公式ベンチマークでのSandy BridgeのMKLによるマルチスレッド並列処理でも同様の傾向を示していました。
Sandy BridgeでのMPIによるマルチプロセス並列処理 (ノード内並列)
Sandy BridgeでMKLによる並列処理の性能が出ない原因として、お客様が着目されたのは通信オーバーヘッドの発生です。数値演算ライブラリMKLによる並列処理は計算の粒度が小さいため通信のオーバーヘッドが大きくなる傾向があり、並列性能の向上が頭打ちなることがあるからです。
もし原因が通信オーバーヘッドにあるなら、並列通信ライブラリMPIを使用した並列処理に変更して、計算の粒度を大きくすることで、通信オーバーヘッドを少なくすることができ、並列性能の向上が頭打ちになることを防げる可能性があります。
そこで、Sandy Bridge上でMPIを用いた並列処理をテストされました。
ところがテストの結果は予想に背くものでした。MKL並列を使用した４並列処理の経過時間は３１１秒、MPI並列を使用した４並列処理の経過時間は３１３秒であり、両者の差は２秒しかありませんでした。
Sandy BridgeのMKL４並列処理の経過時間 ３１１秒
Sandy BridgeのMPI４並列処理の経過時間 ３１３秒
両者の差は２秒
この比較から、MKLとMPIという異なる並列化手法を用いて通信条件を変化させても、４並列処理の経過時間に差が現れないということは、Sandy BridgeでのWine2kの４並列処理で発生しているボトルネックの原因は、並列処理で発生する通信によるものではないと考えることができます。
すると並列処理ボトルネックの原因は消去法でメモリボトルネックだと推定できます。すなわち、通信ボトルネックが発生する前にメモリボトルネックが発生していたということです。
Nehalem Xeon 2CPUでのMKLによるマルチスレッド並列処理 (ノード内並列)
もし並列処理ボトルネックがSandy Bridge Xeon E3が持つ21GB/sという狭いメモリ帯域幅に起因するなら、CPU毎に32GB/sのメモリ帯域幅、システム全体では64GB/sという広いメモリ帯域幅を持つNehalem Xeon X5670 2.93GHz 2CPUで同じテストを実施すると、３倍の速度が得られる筈です。
そこでこの仮説を確認するためXeon X5670 2CPU機を用いたテストを行われました。その結果は次のようなものでした。
Nehalemのシリアル処理の経過時間 ８６０秒
NehalemのMKL２並列処理の経過時間 ５５６秒 (１並列からの時間短縮率 34%)
NehalemのMKL４並列処理の経過時間 ４０９秒 (２並列からの時間短縮率 28%)
NehalemのMKL６並列処理の経過時間 ３７８秒 (４並列からの時間短縮率 8%)
NehalemのMKL１２並列処理の経過時間 ３６３秒 (６並列からの時間短縮率 4%)
(比較対象のSandy BridgeのMKL４並列処理の経過時間 ３１１秒)
Xeon X5670 2CPU機は64GB/sという広いメモリ帯域幅を持ち、かつコア間の通信帯域幅も十分に広い計算機であるにもかかわらず、MKLによるマルチスレッド並列性能は４並列で頭打ちになっていました。
しかも困ったことに、Nehalemの性能は、21GB/sのメモリ帯域幅しか持っていないSandy BrideでのMKLによる４並列処理での経過時間である３１１秒にも及ばない、３６８秒という惨憺たる結果でした。高速なメモリを使っても並列性能が向上しないのですから、メモリ性能がボトルネックの原因ではないことかわかりました。
ここで状況を整理すると、先にも書きましたが、MKLによる並列処理は計算の粒度が小さいため通信のオーバーヘッドが大きくなる傾向があり、並列性能が頭打ちになることがあります。このことから、MKLが通信ボトルネックを発生させているため、メモリ性能が高くて、並列性能の伸びなくなっている可能性があります。
Nehalem Xeon 2CPUでのMPIによるマルチプロセス並列処理 (ノード内並列)
もしMKLの並列処理による通信オーバーヘッドが並列性能が伸びないことの原因だと仮定するなら、計算の粒度が大きいため通信オーバヘッドが小さいとされるMPI並列処理を利用することで、並列性能が伸びる可能性があります。
そこで、それを検証されるためMPI並列処理のテストをNehalem Xeon上で実施されました。
するとNehalem Xeon X5670 2.93GHz 2CPU 12Core機によるMPI並列の１２並列処理で１９４秒という性能が達成されました。
MPIによって並列処理の粒度を大きくできたことで、通信オーバーヘッドの発生が抑制され高い並列性能を実現できたようです。
NehalemでのMKLによる１２並列処理の経過時間 ３６３秒
NehalemでのMPIによる１２並列処理の経過時間 １９１秒
Wine2kの並列処理はメモリ性能とノード内の通信性能の双方に律速されているようです。そのため十分に広いメモリ帯域幅と十分に広いノード内通信の帯域幅の双方が必要であり、しかもノード内通信への負担を小さくするためMPIによる並列処理を利用する必要があるようです。
Nehalem Xeon 2CPU 4node I/Bクラスタでの
MPIによるネットワーク並列処理 (ノード内並列 + ノード外並列)
Wine2kはメモリ性能やノード内通信性能に緩く律速されているようです。そのため、計算機の演算性能が向上しても、メモリ性能やノード内通信性能が向上しなければ、ノード内並列性能の向上は頭打ちになるようです。
Wine2kはこのような現象が発生することがわかっているので、CPUの性能向上に過剰にお金をかけるよりも、ネットワーク並列環境にお金を掛ける方が合理的だと考えられます。
ネットワーク並列処理の特徴は、計算機の演算性能、メモリ性能、ノード内通信性能の全てが、ノード数の増加に応じて直線的に増加することです。そのため並列度を高くしても、これらがボトルネックとなって並列化効率を低下させることがありません。並列化効率を低下させる原因となるものはアプリケーションの内部で行われる並列計算のプリポスト処理や通信処理などです。
お客様がテストで利用されたシステムは４台のNehalem Xeon X5670 2.93GHz 2CPU 12Core機をInfiniBandで接続した4node 8CPU 48Coreのネットワーク並列計算機です。
この並列計算機を用いたネットワーク並列処理のテストの結果をみると、ノード数の増加に応じてリニアな並列性能の向上がみられました。
このネットワーク並列計算機での並列処理性能を比較します。１ノード処理の経過時間は１９１秒、２ノード処理の経過時間は１０１秒であり、高速化率は４６パーセントでした。高い並列処理効率を実現しています。４ノード処理の経過時間は５８秒であり、２ノード並列からの高速化率は４４パーセントでした。
NehalemのMPI１ノード処理の経過時間 １９１秒
NehalemのMPI２ノードネットワーク並列処理の経過時間 １０４秒 (１ノードからの時間短縮率 46%)
NehalemのMPI４ノードネットワーク並列処理の経過時間 ５８秒 (２ノードからの時間短縮率 44%)
ネットワーク並列処理は並列度を増やしても高い並列化処理効率を実現しています。この効率なら１６〜３２ノードの並列計算でも充分に実用的な性能が得られそうです。
まとめ
Wine2kはメモリボトルネックがあるので、システムを選定する場合はメモリ帯域幅を優先する必要があります。CPUのクロック速度はあまり重視する必要がないようです。もし高い性能が必要ならCPUに費やす予算をノード数の確保とネットワーク並列環境の強化に費やすべきです。
また、来年度の中頃から本格的に普及する考えられる２ソケット版のSandy Bridgは、メモリ帯域幅が現在のSandy Bridgeの２．５倍に高速化するといわれているため、現在のSandy Bridge Xeon E3プロセッサの２倍以上の性能向上が期待できます。２ソケット機なら４倍を超える性能です。
しかもWine2kはネットワーク並列処理の効率が良い計算機です。この傾向はSandy Bridge世代になっても受け継がれると考えられます。
お客様から寄せられたベンチマーク結果によって、Wine2kに適した単体の計算機の設計方法と、ネットワーク並列計算機の設計方法について明確にすることができました。
3) Sandy Bridgeの現状と展望
期待に応える開発環境の完成には至っていない模様
現在のHPC計算機は階層的な並列化によってアプリケーションを高速化しています。しかしそれを実現するためには、アプリケーションの並列化と、並列化されたアプリケーションのハードウェアへの最適化という、２つの重い作業を行わなければなりません。
この作業を手作業だけで完遂させることは容易なことではありません。そこで、この作業を支援するため優れた開発環境が必要です。
しかし優れた開発環境を完成させるためには長い開発期間が必要です。そしてその開発期間は、新しいアーキテクチャを搭載した製品が市販されてからも続けられることになります。優れた機能を備えた開発環境が提供されるまでには何年もの期間が必要です。
Sandy Bridgeは発売されてからまだ半年しか経っていない新しいアーキテクチャの製品です。残念なことにSandy Bridgeに最適化された優れた機能を備えた開発環境はまだ本当の意味で完成の域に達していないかもしれません。
Linpack HPLベンチマークテストではSandy Bridgeの性能は発揮された
SPECfp 2006ベンチマークテストではSandy Bridgeの性能は発揮されていない
ここに掲載したWine2kのベンチマークテストで利用されている「Intel Composer XE 2011とIntel MKL」はSandy Bridgeの製品化に合わせ2011年の春にリリースされた開発環境です。
この開発環境を利用してLinpack HPLをビルドし、それをSandy Bridge上で動作させたところコアあたり20GFLOPSの実効性能を、CPUあたり80GFLOPSの並列実効性能を確認しました。条件さえ整えばSandy Bridge上でAVXは十分に高速に動作します。
ところが業界標準のベンチマークテストであるSPECfp2006については、計算機業界が総力を挙げてAVXの性能を発揮させようとチャレンジしているにもかかわらず、いまだにSandy Bridgeの秘められた性能が顕在化していません。
これは開発環境の開発グループも痛いほどわかっていることで、今も課題の解決に向けて懸命の開発作業を続けている筈です。一刻も早くSPECfp2006で素晴らしい成果が報告されることを願っています。
現在の開発環境でもAVXの性能を引き出すことができた
SPECfp2006でSandy Bridgeの性能が確認できないため落胆していたところに、ここに掲載した２例のベンチマークテスト結果が相次いで寄せられました。これを見ると.条件さえ整えば現在の開発環境でもAVXの性能を引き出すことができるということがわかったことは大きな成果です。
もっとも実際にAVXの性能を引き出した立役者はインテルコンパイラではなく、インテル数値演算ライブラリMKLであったことには注意が必要です。
また、シリアル処理ではAVXの性能が発揮されましたが、並列処理ではハードウェア側のボトルネックによって性能向上は頭打ちになっていました。このハードウェアのボトルネックについても至急解決して欲しいものです。
次期Sandy Bridgeではメモリ帯域幅が改善
現在のSandy Bridgeで問題になっているメモリ帯域幅については次期Sandy Bridge製品で解決される公算です。Wine2kのテストに用いた１ソケット版のSandy Bridge Xeon E3シリーズのメモリ帯域幅は21GB/s (DDR3 1333MHz x 2ch) です。これはサーバ版の旧Nehalem Xeonのメモリ帯域幅 32GB/s (DDR3 1333MHz x3ch) よりも劣っているばかりか、１ソケット版の旧Nehalem i7 980xの25GB/s (DDR3 1066MHz x3ch) にすら劣っています。
これが、次の２ソケット版のSandy Bridgeではメモリ帯域幅が51GB/s (DDR3 1600MHz x 4ch) に高速化されるようです。この性能はSandy Bridge Xeon E3シリーズのプロセッサの２．５倍に達するものです。さらにキャッシュや通信デバイスも細かく改善されると思います。
この計算機を用いれば、Wine2kのノード内並列性能は大幅に向上すると考えられます。
4) Sandy Bridgetが持つ
HPC計算機の高速化に役立ついくつかの特徴
インテルのSandy Bridgeシリーズのプロセッサは、HPC計算機の高速化に役立ついくつもの特徴を持っています。ここではその主なものをご紹介します。
第１の特徴は、新しく搭載されたAVX命令セットによってアプリケーションを高速化することです。AVX命令セットとは、これまで128ビット処理であったSSE命令セットを256ビット処理に拡張することで、浮動小数点演算性能を２倍に高速化できる新しい命令セットのことです。アプリケーションをAVX命令セットに対応させることで最大２倍の高速化を実現できます。
AVX命令セットを使用するためには２つの方法が用意されています。１つめの方法は、AVX命令セットに対応したコンパイラを用いることです。２つめの方法は、AVX命令セットに対応した数値演算ライブラリを用いる方法です。なお、これらの方法は組み合わせて使用することができます。
第２の特徴は、プロセッサの内部通信方式が、これまでのクロスバースイッチ方式から、リングバス方式に変更されたことです。これまでクロスバスイッチ方式は、各処理モジュール間の通信回路が局所的に集中していたため拡張の限界に達していました。これに対してリングバス方式は、通信回路をCPUチップ全体に分散するため局所的な集中が発生せず、より多くの処理モジュールをCPUチップ上に搭載できるようになったとのことです。その結果、より多くのCPUコアやメモリシステム、I/OデバイスなどをCPUチップ上に搭載することが可能になり、CPUのより一層の高性能化に途が拓けたということです。
第３の特徴は、ヘテロジニアスなコア構成のプロセッサが実現される可能性があるということです。科学技術計算では浮動小数点演算を多用するため、それ以外の演算リソースは無駄になりがちです。この無駄を省くためには、科学技術計算に特化した浮動小数点演算専用コアと汎用コアを混載したプロセッサの実現が有望です。
第４の特徴は、メモリ帯域幅の拡大です。２ソケット版のSandy BridgeはDDR3 1600MHzメモリを４チャンネル接続することで50GB/s/CPUのメモリ帯域幅を実現できるといわれています。またキャッシュメモリも高速化と大容量化が進み処理効率も向上すると考えられます。これらの相乗効果によってメモリボトルネックの低減が期待できます。
第５の特徴は、プロセッサの製造により微細な半導体製造技術が導入されることです。これによって、搭載コア数の増大、クロック速度の向上、消費電力の低減などを同時実現することができます。
Sandy Bridgeシリーズのプロセッサは、これらの諸要素の相乗効果によって、将来は200GFLOPSを超える製品が発売される可能性があります。このようなプロセッサを用いるとサーバ１台で１テラフロップス、ブレートサーバ１台で８テラフロップス、ラック４基で１００テラフロップス級のシステムを実現できる可能性があります。
また、プロセッサやメモリの消費電力が低減することで、システム全体を外気で冷却することができるようになると、空調にかかる電力 (電気代) を削減することができるようになる可能性があります。
このように、Sandy BridgeはHPC計算機用のプロセッサとして大きく発展する可能性を持っています。
5) ノード内並列処理とネットワーク並列処理の
双方をシステムに搭載することがシステム構築の基本
Sandy Bridgeに代表されるノード内並列処理による計算機の高速化は目覚ましく進歩しています。しかしこの技術進歩によってネットワーク並列計算機が廃れてしまうようなことはありません。計算機の高速化は階層的な並列化技術の積み重ねによって発達してきた技術の蓄積が厚く、コストパフォーマンスが良いため、この流れは今後も継続すると考えられるからです。
階層的な並列化とは、ベクトル化による演算コアの並列化、マルチコア化によるプロセッサの並列化、マルチプロセッサ化によるシステムの並列化、そしてクラスタ化によるネットワーク並列化、という４階層の並列化のことです。この階層的な並列化の相乗効果によって、初期には４ギガフロップ程度だったPCの理論性能が、僅か１０年強の期間で、１６ノード級の小型のPCクラスタでも、数テラフロップスという３桁に達する高速化を実現するところまで到達しています。
これと同様の性能を３階層の並列化で実現しようとすると、コストが一挙に何倍にも跳ね上がり、難易度は急激に上昇し、信頼性も低下します。
さらにネットワーク並列環境は他の並列環境では実現できな大きな長所を持っています。それは、ノード数の増加に比例してメモリ帯域幅とシステム内通信帯域幅が増えることです。CPU性能はマルチコア化で増やし続けることができますが、メモリ性能と内部通信性能はマルチコア化によって増大することがありません。そのためメモリ性能ボトルネックや内部通信性能ボトルネックが発生する可能性が高くなる場合があります。その問題を解決できるのはネットワーク並列処理です。
これまで高速なネットワークスイッチは価格が高く、それが高速なネットワーク並列環境の普及を阻んでいました。しかし、ネットワーク並列計算機が広く普及したことで、８〜１６ポートの小型スイッチに関しては低価格化が進んでいます。そのため４〜８ノードの小型クラスタにも高速なネットワークスイッチを実装することで総合CPU性能、総合メモリ性能、総合ノード内通信性能のバランスを適当に保つ設計が広く取り入れられるようになっています。
このようにHPC計算機は４階層の並列化を重層的に利用して高速化を実現しています。そして多くのアプリケーションもこの階層を利用して開発されています。そのためシステムを構築にする際は、この４階層の並列化を何時でも使用できるような環境に整えておくことが大切です。たとえすぐにネットワーク並列処理を利用する予定がなくても、高速なネットワークスイッチが導入されていなくても、４階層の並列環境を整備しておくことがシステム設計の基本です。