電話 03-6410-6070、FAX 03-6410-6073 電子メール ｉｎｆｏ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ / ｓｕｐｐｏｒｔ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ (アドレスは半角に変更して利用)
HPC-ProServer DPeM915
4-socket 12-core Opteronを搭載するサーバブレード
高密度実装と高信頼性を両立できるブレード型のHPCクラスタ
サーバブレードのサイズはフルハイト、ブレード筺体に８台内蔵可能
各ブレードは４８基のCPUコアを搭載でき480GFLOPSの理論性能を達成
ブレード筐体全体では３８４基のコアを搭載でき3.8TFLOPSの理論性能を達成
32個のDIMMスロットを搭載でき最大512GBのメモリを搭載が可能
４チャンネルのメモリポートにより42GB/s/CPUのメモリ帯域を実現
2.5インチHDDを最大２台搭載でき1.2TBのディスク容量を実現
Dual Port QDR InfiniBandを搭載でき高速な並列通信を実現
Dual Port 10GbEを搭載でき高速なファイル転送が可能
InfiniBand S/W、10GbE S/W、KVM S/Wなども内蔵可能
３年間の翌営業日オンサイト保守と部品保障を提供
３年間の技術支援を実施
少数の高速コアから多数の低速コアへと
x86系の計算機はManyCore化を目指す !
そのトップランナーHPC-ProServer
DPeM915
プロセッサは発熱問題が原因でクロック速度が上昇しなくなって久しくなります。そのためプロセッサの高速化は階層的な並列化によって実現されるようになりました。
プロセッサは処理速度の向上が常に求められています。現在の技術はそれをプロセッサのManyCore化で実現しようとしています。プロセッサのManyCore化とは、クロック速度の上昇を断念し、その代わりにコア数を増やすことで並列性能を向上させるという設計思想のことです。
プロセッサのManyCore化を支える基盤技術が半導体製造技術の向上です。この技術によって単位面積あたりのトランジスター数が加速度的に増え、その増えたトランジスタを用いてコア数を加速度的に増加させ、その増えたコアを使って並列性能を加速度的に向上させるということです。半導体製造技術の向上は今後も続くと予想されるので、プロセッサの加速度的な高速化も順調に続くと思われます。
１２個のコアを搭載したOpteronプロセッサはプロセッサのManyCore化に先鞭をつけた製品です。HPC-ProServer DPeM915 (以下、DPeM915) はこの１２コアOpteronプロセッサを４個搭載することで４８コアのメモリ共有型計算環境を実現しています。DPeM915はこれから本格的に普及するManyCore計算機を先取りしています。
DPeM915の最大の特徴は業界標準のx86系のアーキテクチャを採用したManyCore計算機であるということです。そのため、開発環境やアプリケーションのソースコードは現在使用しているx86系のものをそのまま使え実用的です。先に述べたように半導体製造技術の向上によって、汎用プロセッサのManyCore化が現実になるため、これからはx86系のManyCore計算機がHPC計算機の主流になる可能性があります。
HPC計算機の高速化にManyCoreが大きな役割を果たすからといって、ネットワーク並列計算機の役割が軽くなることはありません。計算機の高速化は階層的な並列化によって実現されています。ManyCore化による高速化は、プロセッサ内部の高速化をコストを掛けず、消費電力をも増やさないで実現することに意味があるのです。
さらに高速化が必要ならDPeM915をネットワーク並列計算として利用することになります。DPeM915はブレード型サーバです。DpeM915は10Uサイズのブレード筺体に最大８台まで搭載でき、８ノード、３２プロセッサ、３８４コアのInfiniBand接続のネットワーク並列計算機システムを構築でき、３８４コアのネットワーク並列計算機として利用することができます。
ManyCore計算機の主流は
標準的なx86系アーキテクチャで実現
計算機のManyCore化に向けて何種類もの方式が提案されています。それらの多くは独自アーキテクチャを採用した方式です。ところが独自アーキテクチャを採用すると専用の開発環境が必要になります。しかもその開発は難しく完成に時間もかかります。またアプリケーションの移植と最適化も必要になります。しかもそれにも手間と時間がかかります。独自のアーキテクチャを採用したManyCore計算機の実用化は容易ではありません。
これに対して、DPeM915は使いやすいManyCore計算機を目指しています。それを実現するためDPeM915は既存のx86系アーキテクチャを利用できるManyCore計算機です。x86系のアーキテクチャなら、開発環境やOSは既存のものを利用できます。アプリケーションの移植も必要ありません。実用的なManyCore計算機を簡単に実現できます。
これまでの計算機は、計算機技術の標準化と表裏一体で進歩してきました。これを逆に見ると、いかに優れた技術であっても標準化されないものは退いてゆくということを意味します。このことからも、ManyCore計算機の主流は標準的なx86アーキテクチャの延長線上に展開される可能性が高まったと見ることが妥当です。
アプリケーションを並列化するための５種類の方法
計算機の階層的な並列環境を利用するためには、アプリケーションの方も階層的に並列化する必要があります。それには次の５種類の方法が主に用いられています。これらの方法は計算機の階層的な並列環境に対応しているので、これらを組み合わせて利用することができます。次の表は５種類の並列化の方法を整理したものです。
| ５種類の並列化 | 並列処理の階層と 並列化の方法との対応関係 |
各並列化の特性 | |||||
| コア内の 並列処理 |
CPU内の 並列処理 |
ノード内の 並列処理 | ノード間の 並列処理 |
並列化 効率 |
並列 性能 |
開発 難易度 |
|
| コンパイラによる 命令レベルの並列化 |
○ | × | × | × | 高 | 高 | 低 |
| 数値演算ライブラリによる 並列化 |
○ | ○ | ○ | × | 高 | 高 | 中 |
| コンパイラの自動並列化機能による マルチスレッドを利用した並列化 |
× | ○ | ○ | × | 低 | 低 | 低 |
| OpenMPディレクティブを挿入した コンパイラの自動並列化機能による マルチスレッドを利用した並列化 |
× | ○ | ○ | × | 中 | 中 | 中 |
| MPIによる並列化 ノード内のMPIによる並列化 ノード内外のMPIによる並列化 |
× | ○ | ○ | × | 高 | 高 | 高 |
| × | ○ | ○ | ○ | 高 | 高 | 高 | |
これらの方法は長い歴史があります。最も新しいOpenMPでも１５年以上にわたって利用され、それ以外のものは２０年以上にわたって幅広く利用され続けています。この継続性ことが開発環境を利用するうえで最も大切なことです。
開発環境は、ハードウェアに最高の性能を発揮させる機能と、ハードウェアの変化を吸収しアプリケーションに一貫したインターフェースを与える機能との、２つの機能を持っています。
開発環境こそシステム開発の要に位置するのかもしれません。もし開発環境が短命だと、開発に投入した資源が無駄になります。
便利な並列化支援環境
現在のコンパイラが備える自動並列化機能は強力です。しかし、コンパイラによる過度の自動並列化は計算の内容を損ねる可能性があります。これを避けるためには、開発者の側がプログラムを並列計算に適した構造に再構築しておく必要があります。
プログラムを並列計算に適した構造にすると、その効用は、ある時点で計算速度が速くなるだけでなく、その後、ハードウェアの並列度が向上した場合に、その効果をエスカレーター式に引き出すことができることにあります。開発に投入した資源を無駄にすることがありません。
プログラムを並列化に適した構造にするためには、プログラムの並列化を支援するツールを使うことが効果的です。そのようなツールを使うと並列プログラムの実行時に発生するボトルネックやその影響が開発者にわかりやすく伝えられます。そのため開発者は計算アルゴリズムやプログラムの改良を容易に行うことができるようになります。
代表的な並列化支援ツールは「インテル(R) VTune (TM) Amplifier XE (旧、インテル(R) VTune (TM) パフォーマンス・アナライザー) 」です。下にこの製品を紹介するページのリンクを掲載します。
□ "VTune Amplifier XE" 紹介ページへリンク (別ページで開く)
□開発環境の価格表へリンク (別ページで開く)
プロセッサの製造メーカーであるインテルが開発環境まで製造・販売・サポートしていることには理由があります。新しいアーキテクチャを製品化するためには、それに対応した優れた開発環境が必要です。それを早期に発売するためには、新しいアーキテクチャ開発の早期から平行して開発を進めなければなりません。それはインテルの中でしか行えないのです。
これまでインテルは開発環境に関連した技術と人材の拡充に膨大な投資をしてきました。古くはDEC社の開発環境に関連した部隊の受け入れから、最近ではGPGPU関連の技術の導入まで、その幅と厚さは相当のものです。インテルはその蓄積によって今日では最も優れた開発環境を開発できる会社のひとつになっています。
「開発環境を統合」することで
アプリケーションのソースコードを統一
インテルの開発環境が優れていると言っても、それではなぜOpteronのページでインテル開発環境の紹介をするかというと、「開発環境を統合」することでソースコードを統一することができるからです。
Opteronプロセッサとインテルプロセッサは共にx86系のアーキテクチャを採用しています。そのため両者にはバイナリ互換性があり、開発環境を統合しても支障ありません。この互換性はインテルも認めています。
これを受けて、両者が使う開発環境をインテルの開発環境に統一すると次のようなメリットが生まれます。
・ ソースコードを統一できる、 異なる開発環境間での移植が不要
・ ソースコードの保守性が向上する
・ ソースコードの可搬性が向上する
これを別の視点から見ると次のことがわかります。
・ 開発環境がハードウェアの違いを吸収する
・ 開発環境がハードウェアの性能を自動的に引き出す
・ 開発環境がソースコードを統一する
すなわち、並列化によって複雑になるハードウェアの違いを吸収する機能の中心が開発環境であるということです。Opteron、Xeon、ManyCoreが混在しても、その差異を開発環境が吸収し、ソースコードを統一することができます。
その結果、ユーザはソフトウェアを並列処理へ最適化する作業に集中でき、煩雑なソースコードの移植作業と保守作業から解放されます。
| BEFORE | AFTER | |||||
| 複雑な環境 | ⇒ | シンプルな環境 | ||||
| 共通のソースコード | 共通のソースコード | |||||
| Opteron用 追加コード |
Xeon用 追加コード |
ManyCore用 追加コード |
⇒ | |||
| Opteron用 開発環境 |
Xeon用 開発環境 |
ManyCore用 開発環境 |
統一された開発環境 | |||
| Opteron | Xeon | ManyCore | Opteron | Xeon | ManyCore | |
実際に運用されるクラスタの
計算機の構成はかなり複雑
x86系の各計算機の品質が向上したことで、多くの種類の計算機が選択できようになりました。その結果、実際のクラスタの計算機の構成は複雑になっています。
上に掲載した図はある時点に限定したシステムの複雑さだけを表しています。すなわち時間軸は考慮されていません。そこで、上の図に時間軸を加えると、下の図のように地層のように計算機が積み重なることになります。
これらの計算機グループはアーキテクチャやOS、開発環境が異なるため、深いレベルでの互換性は保障されていません。そのため、グループ毎に独立して運用することになり、ソースコードやバイナリも別々に存在します。
各グループは独立して運用されるため、ジョブスケジューラも小さな単位でしか資源管理を行えません。
| アーキテクチャ毎にグループ化され運用されているクラスタ
|
||||
| 歴代 Opteron | 歴代 Xeon | 歴代 ManyCore | ||
| Bulldozer 専用OS 専用開発環境 専用コードmakefile |
4-socket | Sandy Bridge 専用OS 専用開発環境 専用コードmakefile |
4-socket | ManyCore |
| 2-socket | 2-socket | |||
| Mangy-Coure 専用OS 専用開発環境 専用コードmakefile |
4-socket | Nehalem 専用OS 専用開発環境 専用コードmakefile |
4-socket | |
| 2-socket | 2-socket | |||
| Barcelona 専用OS 専用開発環境 専用コードmakefile |
4-socket | Core 専用OS 専用開発環境 専用コードmakefile |
4-socket | |
| 2-socket | 2-socket | |||
これでは計算機資源の有効利用が行えず、快適な環境も実現できません。ソースコードやバイナリのバージョン管理も煩雑になります。
しかしそもそも、システム全体はx86系に統一されていますから、工夫することで全体の互換性を高め、便利に運用できる環境は実現できないのでしょうか。
それを実現するには開発環境の統合が効果的です。開発環境を統合するとアプリケーションのソースコードを共通化することができ、グループ間の互換性が高くなります。注意すればシステム全体を一体のものとして利用することも可能になります。すなわちジョブジューラを用いた全体の管理が可能になります。
マルチコア、ManyCore化された複数の計算機を用いたヘテロジニアスなコンピューテング環境を統合するためには、開発環境の統一が必要であり、そうすることでシステム全体の自動資源管理が可能になります。
| 統合して運用できるクラスタ | ||||
| 共通のx86系ソースコード | ||||
| 共通のx86系開発環境 | ||||
| 歴代 Opteron | 歴代 Xeon | 歴代 ManyCore | ||
| Bulldozer 専用OS |
4-socket | Sandy Bridge 専用OS |
4-socket | ManyCore |
| 2-socket | 2-socket | |||
| Mangy-Coure 専用OS |
4-socket | Nehalem 専用OS |
4-socket | |
| 2-socket | 2-socket | |||
| Barcelona 専用OS |
4-socket | Core 専用OS |
4-socket | |
| 2-socket | 2-socket | |||
ソフトウェアが自動並列化に対応していると
x86系のManyCoreプロセッサによる高速化が期待できる
近い将来、x86系のManyCoreプロセッサが製品化されそうです。従来のx86系プロセッサのコア数は４コアから１２コアでした。それがManyCore化されると３２コアからそれ以上のコア数が搭載されることになります。
x86系のManyCoreプロセッサはコンパイラの自動並列化機能を利用してアプリケーションを最適化するということを前提にして開発されているようです。そのためソフトウェアがコンパイラの自動並列化に対応していると、x86系のManyCoreプロセッサの性能も自動的に発揮される可能性があります。
X86系のManyCoreプロセッサは、「CPU性能律速型アプリケーション」の高速化に劇的な効果を発揮することが期待されています。
性能が出ない場合はボトルネックが発生している可能性があります。その発見には、インテルの並列化支援ツールが活躍します。プロセッサのManyCore化が進むと、アプリケーション・ソースコードが並列化に適した構造になっていることが大切です。
ソフトウェアが自動並列化に対応すると
ソフトウェアのMPI並列も
その延長線上で実現できる
ソフトウェアを並列化する方法は、コンパイラによる自動並列化と、MPIを用いた手動並列化があります。両者の違いは並列化作業を自動的に行うか、あるいは手作業で行うかということです。しかし、ソフトウェアの構造上は両者に大きな違いはありません。
このことからソフトウェアを並列化する順序は、最初がソフトウェアを並列化に適した構造に書き換えること、次がコンパイラによる自動並列化、そしてそのチューニングです。ここまでの作業で希望する性能が得られれば作業は終了です。この後もプロセッサの進歩に歩調を合わせてアプリケーションの高速化は続きます。しかし、さらに高い性能が必要な場合があります。その場合はMPIを用いた並列化に取り組むことになります。
実際に並列処理を行うと、コンパイラによる自動並列化によるものと、MPIを利用して手作業で並列化したものとの間に大きな性能差が現れることがあります。それは多くの場合、並列度を大きくする過程で差が大きく開くようになります。その理由は次のように考えられます。
コンパイラによる自動並列化は計算の粒度が細かくなるため小さな通信が高頻度で発生します。すると並列度が大きくなるに従って通信オーバーヘッドが増大し通信ボトルネックが発生しやすくなります。
これに対してMPIを用いて手動で並列化した場合は計算の粒度が大きいため、通信の頻度も少なく通信ボトルネックが発生しにくくなり並列性能が伸びやすくなります。しかも、通信ボトルネックが発生しても手作業でソフトウェアを改良し、ボトルネックの発生を抑えることができます。
コンパイラによる自動並列化は通信ボトルネックが発生しやすい反面、プログラミングは容易です。ところがMPIを用いた並列化は、通信ボトルネックが発生しにくいという長所の反面、プログラミングが難しいとう短所があるのです。
そのため、アプリケーションを並列化する場合は、最初にコンパイラによる自動並列化を試し、さらに高速化が必要になった場合は、MPIによる手動の並列化に着手するとアプローチになるのです。
しかし、双方にとって必要不可欠なことはアプリケーションが並列化に対応した構造をしているということです。
1. 姫野ベンチを用いた自動並列化コンパイラのテスト
シリアル版 (非並列版) の姫野ベンチを
普通にコンパイルした場合と
コンパイラの自動並列化でコンパイルした場合の比較
ここで実際に自動並列化コンパイラはどの程度の実力を備えているのかを確認してみます。テストには理研で公開されている「姫野ベンチ」を利用しました。使用するソースコードは非並版と並列版の両者を用い、コンパイラ・オプションを変更しながら、実際の挙動を調べました。
テストに用いた計算機はXeon X5680 3.33GHzのプロセッサを２基搭載した１２コアの計算機です。コンパイラは最新のIntel Compiler 12.0.4.191を使用しました。
最初にシリアル版の himenoBMTxp.f90 を普通にコンパイルしてシリアル計算させた結果と、 同じソースコードを "-parallel" オプションを付けてマルチスレッドによる自動並列化を行った計算結果を比較しました。すると、自動並列化版で２並列処理した場合の処理速度はシリアル処理の半分まで低下していました。並列化に対応していないソースコードを自動並列化すると性能が低下する場合があるということです。
ここで念のために他のコンパイラでもシリアル処理版のソースコード himenoBMTxp.f90を用いて自動並列化し同じテストを行いました。すると驚いたことに他のコンパイラではhimenoBMTxp.f90での１２並列の性能は、並列処理版のhimenoBMTxp_omp.f90をインテルコンパイラで "-openmp" オプションを付けて並列化した場合と近い性能を発揮していました。自動並列化コンパイラは十分な性能を備えているようです。ところが、結果を確認すると大きな誤差が出ていました。このことから、コンパイラによる自動並列化で性能を出すことは難しい技術でないということです。しかし、コンパイラがソースコードに過度に介入し無理に性能を発揮させると、その反作用として計算精度の問題が発生する場合があるということがわかりました。
コンパイラがソースコードに過度に介入し計算結果を狂わせること避けるためインテルが選択した解決策は、コンパイラに過度に強力な自動並列化機能を載せるのではなく、ソースコードの改善が必要な箇所を開発者に示し、開発者がアルゴリズムを検討しながらソフトウェアの最適化をすすめられることが容易にできるような環境を提供することに注力しているようです。
2. 姫野ベンチを用いた自動並列化コンパイラのテスト
並列版 (OpenMP版) の姫野ベンチを
コンパイラの自動並列化でコンパイルした場合
次にコンパイラによる自動並列化に対応するために開発されたOpenMP版のhimenoBMTxp_omp.f90 を利用した場合を検討します。
himenoBMTxp_omp.f90を普通にコンパイルしてシリアル計算した結果は、himenoBMTxp.f90を普通にコンパイルしてシリアル計算した結果より約9%遅くなっていました。himenoBMTxp_omp.f90はソースコードを並列処理に対応させたことによって約9%のオーバーヘッドが発生しているようです。
次にhimenoBMTxp_omp.f90を "-parallel" オプションを付けてマルチスレッドによる自動並列化でコンパイルしたバイナリを並列動作させました。すると１並列から２並列への性能の伸びは１．１６倍、２並列から４並列の伸びは１．７５倍、４並列から８並列の伸びは１．３１倍でした。１２並列ではシリアル版の２．７５倍の速度の伸びがありました。
速くなっていますが、効率は良くありません。ソースコードを並列処理に適した構造に書き換えると、自動並列化でも一定の並列性能が出ることがわかりました。これは、インテルコンパイラの "-parallel" オプションは安全な並列処理しか行いません。そのため結果は信頼できますが、高い性能を発揮させることは困難なようです。
では次に、同じくhimenoBMTxp_omp.f90を用いて "-openmp" オプションを付けてOpenMPを利用した本来の性能を確認してみました。すると１並列から２並列への性能の伸びは１．８７倍、２並列から４並列の伸びは１．４１倍、４並列から８並列の伸びは１．３１倍と順調に性能が伸びています。１２並列ではシリアル処理の３．７倍の速度の伸びがありました。
OpenMPのディレクティブによって処理の無駄が省かれています。MPIを利用せず、OpenMPを利用するだけでもある程度の性能が得られることがわかりました。
◎テスト環境
Server : HPC-ProServer DPeM610
Processer : Xeon X5680 3.33GHz 2CPU 12-core
OS : CentOS5.5
Compiler : Intel Compiler 12.0.4.191
姫野ベンチ(Fortran90 シリアル版) :
himenoBMTxp.f90
姫野ベンチ(Fortran90 OpenMP並列化コード) :
himenoBMTxp_omp.f90
◎ベンチマーク結果
| 並列度 | 並列化種別 | |||
| himenoBMTxp.f90 Fortran90 シリアル版 |
himenoBMTxp_omp.f90 Fortran90 OpenMP並列化版 |
|||
| インテルコンパイラ マルチスレッド自動並列化 -parallel (MFLOPS) |
他のコンパイラ マルチスレッド自動並列化 (誤差が大きいため参考値) |
マルチスレッド自動並列化 -parallel (MFLOPS) |
OpenMP自動並列化 -openmp (MFLOPS) |
|
| 1 | 4147 (-parallel無し) | (3118) | 3813 (-parallel無し) | |
| 2 | 2426 | (6217) | 4444 | 7106 |
| 4 | 2589 | (12222) | 7692 | 10082 |
| 6 | 2428 | (13336) | 9381 | 12626 |
| 8 | 2480 | (13481) | 10113 | 13106 |
| 12 | 1813 | (13839) | 10459 | 14253 |
３種の代表的な計算機でのLinpack HPLの結果から
OpenMPとMPIのノード内並列計算の性能を比較
最後にLinpack HPLでのOpenMPとOpenMPIの性能を比較します。比較は代表的な３種類の計算機すなわち、4-socket Opteronと、4-socket Xeon、2-socket Xeonで行い、その結果を表にしています。
テストした計算の種類は、OpenMPによるスレッド並列処理、OpenMPIによるノード内ネットワーク並列処理、そしてOpteronについては並列処理度を変化させて平行処理を行った結果です。
最初に単体コアの処理効率を見ます。OpteonコアはXeonコアよりも10%も効率が低いです。これは並列度が高くなっても同じ効率の低さです。このことからOpteonコアの効率はいかなる場合でもXeonより約10%低いことがわかりました。
次に4-socket OpteronによるOpenMPIでの単体コアの効率は88%、４８平行処理の効率は84%でした。また４８並列処理の効率は71%でした。
これに対して4-socket Xeon X7500番台のプロセッサの単体コアの効率は100%、３２平行処理の結果は無く、３２並列処理の効率は80%です。
4-socket Opteronと4-socket Xeonを比較すると、Opteronのコアの効率の低さを差し引けば、ほぼ同等の並列／平行処理効率を示しています。
次に2-socket Xeon X5690番台での結果を見ると、単体コアの効率は95%、８平行処理の結果は無く、８並列処理の効率は88%です。(ちなみにOpteronは83%、4-socket Xeonは90%です)。単体コアの性能の差を用いて８並列処理での効率を補正すると2-socket Xeonの効率は93%、Opteronの効率は93%、4-socket Xeonの効率は90%になります。8並列の平行処理の効率はほぼ同じです。
次に4-socket XeonでのOpenMPとOpenMPIの差異を比較します。すると８並列まではOpenMPの効率はOpenMPIの効率と並んでいますが、８並列以降はOpenMPの効率が低下していますが、OpenMPIの効率はあまり低下していません。これはOpenMPでの通信の粒度が細かいため通信ボトルネックが発生しているのに対して、OpenMPIでは通信の粒度が大きいため通信ボトルネックが発生していないようです。このOpenMPとOpenMPIの特性の違いの理解は重要です。
| 4-socket 12-core Opteron (45nm, Magny-Cours) | N値 | 1node | 2node | 4node | ||||||||
| 4CPU | 8CPU | 16CPU | ||||||||||
| 1core | 2core | 4core | 6core | 8core | 12core | 48core | 96core | 192core | ||||
| 10 05 28 |
ProServer DPeR815 12-core Opteron 6174 2.2GHz 12MB HT3、(45nm, Magny-Cours) DDR3-1333MHz 256GB (8GB x32) 1-node 4-socket、4CPU、48core gcc-4.1.2、ACML4.4.0 |
OpenMPI (効率) |
15000 | 7.6 (86%) |
||||||||
| 30000 | 7.7 (88%) |
58.4 (83%) |
301.4 (71%) |
|||||||||
| OpenMPI の平行 処理 (効率) |
15000 | 7.3 1x48job (計350) (83%) |
||||||||||
| 23000 | 7.4 1x48job (計355) (84%) |
|||||||||||
| 30000 | 14.3 2x24job (計344) (81%) |
|||||||||||
| 28.4 4x12job (計340) (81%) |
||||||||||||
| 42.3 6x8job (計338) (80%) |
||||||||||||
| 55.1 8x6job (計330) (78%) |
||||||||||||
| 82.8 12x4job (計331) (78%) |
||||||||||||
| 158.9 24x2job (計318) (75%) |
||||||||||||
| (ideal) | - | 8.8 | 17.6 | 35.2 | 52.8 | 70.4 | 105.6 | 422.4 | ||||
| 4-socket 8-core XeonMP (45nm, Nehalem-EX) | 1node | 2node | 4node | 8node | ||||||||
| 4CPU | 8CPU | 16CPU | 32CPU | |||||||||
| 1core | 2core | 4core | 8core | 16core | 32core | 64core | 128core | 256core | ||||
| 10 06 18 |
ProServer DPeR910 4CPU 32core (HT off) X7560 8-core XeonMP 2.27GHz、Nehalem-EX QPI 6.4GT/s (Turbo 2.66GHz) DDR3-1333MHz 256GB Intel Compiler 11.1、MKL 10.2 IntelMPI 1.4.1、HPL 2.0、CentOS5.5 |
OpenMP (効率) |
15000 | |||||||||
| 30000 | 9.3 (102%) |
35.1 97(%) |
69.9 (96%) |
127.4 (80%) |
148.0 (51%) |
|||||||
| OpenMPI (効率) |
30000 | 35.8 (99%) |
65.1 (90%) |
133.9 (84%) |
233.1 (80%) |
|||||||
| (ideal) | - | 9.08 | 18.2 | 36.3 | 72.6 | 159.8 | 290.6 | |||||
| 2-socket 6-core Xeon (32nm, Westmere) | 1node | 2node | 4node | 8node | 16node | |||||||
| 2CPU | 4CPU | 8CPU | 16CPU | 32CPU | ||||||||
| 1core | 2core | 4core | 8core | 12core | 24core | 48core | 96core | 192core | ||||
| 11 06 27 |
ProServer DPeT710 2CPU 12core (HT off) X5690 6-core Xeon 3.46GHz 12MB、Westmere QPI 6.4GT/s Intel 5520 Chipset DDR3-1333MHz 48GB Intel Compiler 12.0.4.191、MKL 10.3-4 IntelMPI 4.0.2.003、OpenMPI 1.4.3 CentOS 5.5 (Final) HPL 2.0 |
SSE OpenMP (効率) |
30000 | 13.1 (95%) |
25.4 (92%) |
49.6 90(%) |
96.6 (88%) |
135.7 (82%) |
||||
| SSE OpenMPI (効率) |
13.1 (95%) |
25.7 (93%) |
50.3 (91%) |
96.6 (88%) |
134.3 (81%) |
|||||||
| SSE IntelMPI (効率) |
13.1 (95%) |
26.0 (9%4) |
50.9 (92%) |
99.7 (90%) |
142.0 86%) |
|||||||
| SSE 理論 性能 |
- | 13.8 | 27.6 | 55.2 | 110.4 | 165.6 | ||||||