ソフテック・トップページへ
ホーム 製品 セキュリティ・サービス HPCサービス ダウンロード 企業情報

PGI compiler TIPS
PGI & Athlon64 X2 デュアルコアの性能
最適化・性能情報 > Athlon64 X2 ベンチマーク
 
  

  低価格のデュアル Athlon64 X2 プロセッサ・システムを
PGI コンパイラで評価する!

2005年4月以降にマルチコア・プロセッサとして、インテル社からPentium(R) D、AMD 社からOpteron/Athlon64のデュアルコア・プロセッサが発売されました。PGIコンパイラも各社のデュアルコア・プロセッサに対応するコンパイラを PGI 6.0-5 においてリリースしました。PGI コンパイラは、EM64T/AMD64 の Pentium(R) D、Opteron/Athlon64 X2 の全てのものに対応可能ですが、ここでは、Opteronプロセッサに代表される NUMAアーキテクチャにおける基本プロセッサと同じ Athlon64 X2 プロセッサの性能試験を PGI コンパイラによる実証試験を兼ねて行いましたのでその結果を示します。これは、HPC用途において低価格Athlon64 X2は使えるのかと言う試験でもあります。また、Opteronの性能評価の記事は、インターネット上で結構見つけることができますが、 Athlon64 X2の性能はほとんど提示されていないこともその理由の一つです。インテル社のPentium Dのアーキテクチャは、基本的には従来の外部チップセットによるバス接続 SMP アーキテクチャであり、大きな変革はないため今回は試験を行っておりません。(PGI コンパイラにおいては問題なく動作します)
今回、試験のために用意したハードウェアは、最高の部材を備えたPCではありません。メモリも少々遅めのノーブランド製品を使い、一般的な汎用品として購入するようなPCを使用しました。したがって、ここで表す性能は、ハードウェア・ベンダーが最高の部材を使用して表すベンチマーク性能とは異なることに注意してください。しかし、安価なシステムにおいても、PGIコンパイラを使用して得た結果はかなり良い性能を提示しています。

ご参考 : Intel(R) デュアルPentium(R) Dプロセッサ・システムでもPGIコンパイラの高速性が実証される !!

使用したシステム機材
デュアルコア対応 Linux ディストリビューションの検証について

表-1  64-bit AMD Athlon64X2 システムの仕様
AMD Dual Core プロセッサ
システム名 White Box (15万円)
プロセッサ AMD Athlon64X2 4400+
(1プロセッサ/2コア)
Clock 2.2 GHz
L2 cache 1MB + 1MB
マザーボード  MSI K8N Neo4 Ultra
使用メモリ(最大帯域) DDR400 PC3200 CL3 3-3-3 (6.4GB/s) 512MB x 2 枚(ノーブランド製品)
CPU FSB (MHz) 200 x 4 (6.4GB/s)
HyperTransportTM 6.4GB/s
使用 OS Fedora Core 4 (kernel 2.6.13.1)
64ビット環境 AMD64
使用コンパイラ PGI 6.0
 
  • プロセッサに関しては、2.2GHz の 1M キャッシュを備えた Athlon64 X2 4400+ を使用した。特に、プロセッサの L2 キャッシュは、多少高くても大きい方が性能に貢献する。 HPC用途の場合は、1M キャッシュのものを推奨する。
  • メモリに関しては、今回安いバルク製品のものを使用してみた。また、 CL3 のため、 CL2.5 のものよりも性能が悪いことは自明であるが、このようなメモリで実効メモリバンド幅がどの程度出るかの検証を行った。HPC 用途では、純正品で性能が保証されたメモリ部材を使用することを推奨する。プログラムの実効性能は、プロセッサのよし悪しよりも、メモリのデータ転送性能に大きく依存するため、プロセッサの選択に悩むより、実装されているメモリモジュールの性能の見極めをしっかり行った方が良い。PCを購入する際には、購入ベンダーに問い合わせることをお勧めする。「購入プロセッサのクロックの選択で悩むより、しっかりしたメモリを実装した製品を選択した方が、全体性能に大きく貢献する」
  • 商用の Linux distribution の Athlon64 X2 (デュアルコア)対応は、2005年8月現在、未だ不十分と言える。今回は、RedHat Enterprise Linux 4 update 1 からさらに、Kernel を 2.6.12 に引き上げて、カスタム・バージョンとして実装した。NUMA&Dual Core 関係のバグが 2.6.12 以降でほぼ フィックスされつつあり、2005 年8月29日に Linux 2.6.13 がリリースされたため、このカーネルにおいては、ほぼ問題なく NUMA&デュアルコアが動作するものと思われる。(これについては弊社で保証するものではありませんので、詳細は、ベンダーにお問合せください)
  • デュアルコア対応の Linux はむしろ、Fedora Core 4 の方が、新しいカーネルアップが簡単なため、こちらの方が向いている。弊社での試験によれば、8月末現在、SuSE Professional 9.3 並びに RedHat Enterprise Linux 4 上のオンライン・カーネル・アップデートにおいても、Kernel 2.6.12 に至っていない。したがって、本来のプロセッサ処理性能がでない不十分な状態にある。これは、まもなく対応されると思われるが、PCを購入する際は、ベンダーに是非ご確認していただきたい。
    【2005/10/20】
    Kernel 2.6.13 において、ほぼ Dual Core 関連のメモリ周りのバグはフィックスし、安定的な性能が得られることを確認した。現在、2.6.13 以上をサポートしているのは、Fedora Core 4 並びに SUSE 10.0 である。
HPC 用途では、実効メモリバンド幅とメモリ・アーキテクチャが重要

HPC分野のアプリケーションは、配列(ベクトルデータ)計算で代表されるようにメモリのアクセスを多用する。アプリケーションの性能の決め手は、もちろんプロセッサの能力であることは確かだが、プロセッサへのデータ供給が滞ると性能は大きく低下する。その意味で、メモリの実効バンド幅は、性能を左右する最も重要な指標である。もちろん、プロセッサの性能とメモリのデータ供給性能の間を埋めるのは、L2 キャッシュではあるが、そのサイズによって性能に影響するものの、1GB、2GB と言った様な解析規模の大きなデータ配列を扱う計算の場合は、実際のメモリデータのバーストレート(実効バンド幅)がアプリケーションの性能を決めることになる。特に、デュアルコアの場合は特に重要である(遅いメモリほど並列効果が出にくい)。
メモリアクセスの実効的性能を決める要素は、.瓮皀螢皀献紂璽襪寮能、▲瓮皀蠅離◆璽テクチャ、コンパイラによるメモリアクセス方法並びに配列処理の最適化レベルである。,麓ずから、高速なメモリモジュールを実装することが第一である。△蓮▲丱好ロック、メモリのコントローラやメモリモジュールの配置によって性能が変化する。現在のインテルのプロセッサのシステムと AMD のプロセッサ・システムでは、そのメモリアーキテクチャは大きく異なる。これについては後で説明する。のコンパイラによるキャッシュ有効利用のための最適化能力も性能を左右する。以下の図は、メモリの実効バンド幅の性能を試験する STREAM ベンチマークの測定結果を示したものであるが、gcc、PGI、PathScale コンパイラによる結果を図示した。明らかに、使用するコンパイラによって差が出ていることが分かる。PGI 6.0 バージョンにおいては、PathScale コンパイラによる性能を上回った。また、Pentium4、Xeon EM64T では、現在のところ STREAM ベンチマークデータにおいても、3700MB/sec 程度が最大の性能値と言うことになり、Opteron システムのメモリバンド幅の優位性が明らかである。なお、以下の性能は、 Opteron 2.2GHz 1Mcache / DDR400 PC3200 CL2 のシステムで得られた結果である。


(注意) 性能試験、ベンチマーク性能並びにその評価は、使用するコンピュータ・システム並びに搭載コンポーネントにより変化します。ここで表示している性能値は、PGI 社並びに弊社が特定のシステムにおいて測定した性能値を表示したものであり、システムのハードウェア・ソフトウェア構成が異なる場合は、実際の性能値が異なる場合があります。

次に、インテルのプロセッサのシステムと AMD のプロセッサ・システムのメモリアーキテクチャの違いについて述べる。
AMD の Opteron / Athlon64 X2 は、プロセッサ内部にメモリと直結するメモリコントローラを持っている。一つのみのプロセッサのシステムでは、直結されたメモリと言うイメージとなるが、Opteron 2-way、4-way 等のマルチプロセッサのシステムにおいては、個々のプロセッサにおいてメモリコントローラを経由しメモリモジュールが直結されている形態となる。さらに、それぞれの個々のプロセッサに接続されたメモリは、他のプロセッサからも プロセッサ間の Hypertransport 技術により、アクセス可能となる。論理的には、全てのメモリモジュールが全体のメモリシステムとして「共有される形態」となる。いわゆる、SMP システムと同じ。但し、従来の全てのプロセッサがバス経由で一つのメモリシステムにアクセスする形態とは異なり、アクセスしようとするメモリモジュールが他のプロセッサに接続されたものであった場合は、そのアクセスまでの遅延度が異なるため、このようなアーキテクチャを NUMA (Non Uniform Memoriy Architecture:不均一なメモリ構成)と言う。これは、共有メモリシステムでの性能スケーラビリティの飽和性を回避するために有効なアーキテクチャであり、SGI 社の Origin、Altix システム等で採用されている高度なアーキテクチャである。一方、インテル社の Xeon(R) システムのような従来型のバス接続の共有メモリは UMA と言うが、プロセッサ外部のチップセット上のメモリコントローラを通して、全てのメモリモジュールにアクセスする。この方式のデメリットは、メモリバンド幅が飽和するため、性能スケーラビリティの観点で多くのプロセッサを接続できないことにある。
複数のプロセッサから構成される SMP システムの場合は、メモリアーキテクチャ的には並列性能が向上しやすい AMD の方が優れているが、1-way のシステムの場合は、あまり気にする必要もない。実効メモリバンド幅が高いものが良いであろう。ところで、SMP 構成の場合、Opteron のシステムの場合は、最大 8-way までのシステムを実装可能である。一方、Xeon(R) ベースのものは、2005年8月現在、最高 4-way までのものとなっている。

PGI コンパイラは、AMD 社の NUMA アーキテクチャにも「最適化」する機能を有するだけでなく、インテル社の従来の UMA アーキテクチャにも最適化可能なコンパイラです。

コンパイラ技術は、AMD64/EM64T のコード生成機能だけではなく、NUMA/UMA と言ったメモリアーキテクチャに対しても柔軟に最適化できる能力が求められている。PGI コンパイラは、次世代 NUMA アーキテクチャに対しても最適化機能を有した「先頭を走るコンパイラ」です。 ==> 商用コンパイラの性能比較

(参考)

シングルコアとデュアルコアのメモリアクセスとその性能に関する留意点

現在のところ、従来のシングルコアのシステムアーキテクチャの上に、CPU のみを二つのコアにして乗せ変えたと言うイメージが、デュアルコア・アーキテクチャの真の姿である。したがって、メモリアーキテクチャの部分だけ見ると、従来のシングルコアで使用していたメモリ構造をそのまま使用するため、メモリバンド幅は、デュアルコアによって2倍になるのではなく、従来のバンド幅 (Opteron では、最高 6.4 GB/sec) を二つのコアで共用すると言うイメージとなる。この点が、マルチスレッドの並列性能に深く関係してくる。例えば、デュアルコアのプロセッサ上で、2CPU の並列処理を行う場合、非常にメモリアクセスの特性の高いアプリケーションでは、大きな並列効果が得られない場合がある。一方、メモリアクセスが軽い演算特性のものでは、理想的な並列効果が得られる。これらは、メモリバンド幅を二つのコア(スレッド)で共用するために生じる現象である。シングルコアの 2-way の Opteron においては、それぞれの CPU のメモリバンド幅が 6.4GB/sec であり、トータル最高 12.8 GB/sec のデータ供給能力を有する。それに対して 1-way デュアルコア においては、6.4GB/sec に過ぎない。

(参考) AMD Opteron プロセッサ 主なアーキテクチャ上の特長

メモリアクセスが重い、軽いと言う表現は、抽象的な表現であるが、簡単なイメージとしてはプログラム上の DO ループ内の配列演算において、右辺側の演算項が多いパターンと考えればよい。一般的に、右辺の演算項を多くするプログラミングによって、CPU の加算、乗算器の多重利用を促し、単位時間当たりの演算効率を向上させ性能を上げる作法であるが、当然ながらそのためにメモリ(演算用のデータ)のアクセスも多用される。このようなアプリケーションの特性によって、デュアルコア 2 スレッドの並列性能は左右される。並列効率が良い場合も悪い場合もあり得るということを認識していただきたい。この並列効率に関して、NAS Parallel Benchmark を使用して評価した結果は、この後に説明する。

PGI コンパイラ による STREAM ベンチマークでの Athlon64 X2 実効メモリバンド幅

STREAM ベンチマークは、非常に単純な演算によるメモリのロード/ストアの性能を測定するベンチマークである。プロセッサのキャッシュの効果を反映させないように、非常に大きな配列間のロード/ストアの性能を測定できるようにベンチマークを行うものである。このベンチマークの性能は、主に、プロセッサの実メモリバンド幅を測定する目的と、コンパイラによるメモリ・ロード/ストア廻りの最適なコード生成が行われているかどうかを見るための重要な指標となる。実メモリバンド幅の性能は、実アプリケーションのデータのアクセス性能の基本となるため、性能全体を左右する重要な指標である。

ここでは、上記表-1 に示すシステムの Athlon64 X2 の実際のメモリバンド幅を以下に示す。なお、このシステムのメモリモジュールは、CL3 のバルク製品であり、性能的にあまりよくないものであるが、以下のように triad(加・乗算) 演算において、 4.29GB/sec を示している。これでもまだ、良好の数字であると言えるであろう。Athlon64 X2 の最大メモリバンド幅は、Opteron プロセッサと同様、6.4GB/sec であり、その67% 程度の実効値を示している。 Opteron とそれに対応するメモリモジュール搭載した場合は、上記の図で示したおり、4.58GB/sec であり、最大実効値はこの程度の性能が出ても良いのであるが、使用部材の違いによってこれだけの性能差が出てくることが分かる。

$ pgf90 -fastsse -O3 -Mprefetch=distance:8,nta  -Minfo  stream.f -DUNDERSCORE mysecond.c
$ a.out
----------------------------------------------
 Double precision appears to have 16 digits of accuracy
 Assuming 8 bytes per DOUBLE PRECISION word
----------------------------------------------
 Array size =    9000000
 Offset     =          0
 The total memory requirement is  205 MB
 You are running each test  10 times
 --
 The *best* time for each test is used
 *EXCLUDING* the first and last iterations
 ----------------------------------------------------
 Your clock granularity/precision appears to be      1 microseconds
 ----------------------------------------------------
 Function     Rate (MB/s)  Avg time   Min time  Max time
 Copy:       3986.8231      0.0361      0.0361      0.0363
 Scale:      4030.5624      0.0357      0.0357      0.0357
 Add:        4330.6596      0.0499      0.0499      0.0499
 Triad:      4290.6652      0.0504      0.0503      0.0504
 ----------------------------------------------------
 Solution Validates!
 ----------------------------------------------------

公開されている STREAM ベンチマーク結果では、常に最高の性能値が記録されているため、この性能にはコンパイラによるループ内のベクトル化によるSSE、プリフェッチ最適化の効果も含まれている。すなわち、コンパイラの最適化能力も含めた性能であるといえる。しかし、一般的なプログラム動作において、本来の実効メモリアクセス性能を把握するためには、このベクトル最適化を disable にして評価することも重要である。こちらの性能の方が、多くの場合性能を支配する指標となる。(一般的には、コンパイラオプションを -O2 として、ベクトル最適化を行わないコードを生成して測定する)

この場合、以下のように PGI コンパイラが生成したコードを使用すると、triad(加・乗算) 演算において、 2.55GB/sec を示している。ベクトル最適化したコードに比べ大分、性能が低下することが分かる。これは、「使用しているメモリSDRAM部材」の性能が悪いことによるもので、使用するハードウェアによって大きな差が出る部分である。見かけ上、同じハードウェア仕様であっても各システムベンダーが提供するマシンの性能が大きく異なるのは、このような使用部材、BIOS等の最適化の違いが出ているのである。

【PGIのベクトル最適化を Disable にした場合、普通の場合のメモリアクセス性能】

$ pgf90 -O2 -Minfo stream.f -DUNDERSCORE mysecond.c
$ a.out

----------------------------------------------
 Double precision appears to have 16 digits of accuracy
 Assuming 8 bytes per DOUBLE PRECISION word
----------------------------------------------
 ----------------------------------------------
 STREAM Version $Revision: 5.6 $
 ----------------------------------------------
 Array size =    9000000
 Offset     =          0
 The total memory requirement is  205 MB
 You are running each test  10 times
 --
 The *best* time for each test is used
 *EXCLUDING* the first and last iterations
 ----------------------------------------------
 ----------------------------------------------
 Printing one line per active thread....
 ----------------------------------------------------
 Your clock granularity/precision appears to be      1 microseconds
 ----------------------------------------------------
 Function     Rate (MB/s)  Avg time   Min time  Max time
 Copy:       4026.3976      0.0358      0.0358      0.0361
 Scale:      2340.2449      0.0616      0.0615      0.0620
 Add:        2807.0931      0.0770      0.0769      0.0770
 Triad:      2551.8044      0.0847      0.0846      0.0847
 ----------------------------------------------------
 Solution Validates!
 ----------------------------------------------------
PGI コンパイラ による 姫野 ベンチマークでの Athlon64 X2 の性能は良好!

姫野ベンチマークは、カーネル・ベンチマークの一つではあるが、演算密度が非常に高い特性に対し演算器の多重利用性と高いメモリバンド幅を備えることによって、実プログラムが達成できる最大の実効性能値を得ることができる。その意味で、これにはコンパイラの能力にも依存する。また、これは異なるプラットフォームにおける性能比較、あるいはプラットフォームの性能同定において有効である。なお、このベンチマークは、メモリアクセスが極めて intensive でありデュアルコアのベンチマークには馴染まないため、1コアの性能を示す。また、L2キャッシュのサイズにより、キャッシュを有効に使用できるデータサイズ規模であれば、このベンチマークの並列効率は Athlon64 X2 においても 2 倍に近い数字を呈する。これは、システムの実用上真の性能を表すものではないため、割愛する。
以下に、PGI 6.0 コンパイラと Athlon64 X2 を使用した性能結果を示す。このシステムではメモリモジュールが遅いため、適確なメモリを実装すると以下の数字よりもさらに大きな数値が得られるものと思われるが、F90 コードの Sサイズデータ (128x64x64) を使用して 1066MFLOPSMサイズデータ (256x128x128) では 1007MFLOPS の性能が得られた。ここで特筆すべきことは、Mサイズにおいても大きな性能低下がないことである。
ちなみに、他社ベンダーが公開している Pentium D 840 3.2GHz/2MB(L2) Dual-Core DDRII-533 FSB800 とインテルコンパイラ バージョン 9.0 との組合せでは、Sサイズデータ1004 MFLOPSMサイズデータ 894MFLOPS と言う数字が公開されている。
以下のPGI コンパイラによる性能は、PGI 6.0-5 (pgf90 -fastsse オプションのみ)を使用して測定された結果である。なお、 Pentium(R) D での測定結果は、株式会社エッチ・アイ・ティー様の公開ページから引用させていただいた。
以下の表から分かることは、プロセッサ、メモリアーキテクチャの違いによる性能差が出ていることは明らかであるが、Pentium(R) D の性能がそれほど大きく伸びていない。姫野ベンチマークはメモリ帯域をフルに使用する特性があることは前述したとおりであるが、計算サイズを S から M にした場合の性能低下率が Athlon64 X2 + PGI の性能より大きいことは、ハードウェア性能よりむしろ、使用コンパイラの違いによるキャッシュ利用に関するコンパイラの最適化能力の差に依る影響も関係していると思われる。

PGI コンパイラとインテルコンパイラの性能比較
Dual Core プロセッサ 1コア性能
プロセッサ Athlon64 X2 Pentium® D 840
Clock 2.2GHz 3.2GHz
L2 cache 1MB + 1MB 1MB + 1MB
64ビット環境 AMD64 EM64T
使用コンパイラ PGI 6.0 インテル 9.0
姫野ベンチ S サイズ(F77 code) 1366MFLOPS -
姫野ベンチ M サイズ(F77 code) 1294MFLOPS -
姫野ベンチ S サイズ(F90 code) 1066MFLOPS 1004MFLOPS
姫野ベンチ M サイズ(F90 code) 1007MFLOPS 894MFLOPS
S->M サイズでの性能低下率 6 % 11 %

(注意) 性能試験、ベンチマーク性能並びにその評価は、使用するコンピュータ・システム並びに搭載コンポーネントにより変化します。ここで表示している性能値は、PGI 社並びに弊社が特定のシステムにおいて測定した性能値を表示したものであり、システムのハードウェア・ソフトウェア構成が異なる場合は、実際の性能値が異なる場合があります。


PGI コンパイラ による Athlon64 X2 上でのマルチスレッド並列性能も良好!

Athlon64 X2 のデュアルコア環境における2並列性能の評価のために、NAS Parallel Benchmark 3.2 の OpenMP ベンチマークの結果を以下に提示する。NPB ベンチマークの詳細については、同志社大学の三木研究室のページに詳細に記述されておりますので、こちらをご覧ください。以下の表では、計算のデータサイズを W, A, B について測定した結果を表示している。1スレッドの絶対性能も低価格なシステムでありながら、非常に良い数値を示している。
1スレッドと2スレッド計算での性能比(並列化効率)を各サイズ毎に示しているが、プログラムのメモリアクセス性の特性によって、効率が異なる。一部のプログラムを除いて、ほぼ妥当な並列化効率と言える。例えば、EP (乱数発生)のようにメモリ競合がないプログラムでは、2倍の効率を得ることができる。今回は上述したとおり、メモリモジュールにバルク製品を使用しており、必ずしも高速なメモリではないが、高速かつ適確なメモリを搭載することによって、この並列効率はさらに向上するものと思われる。MG に関しては、メモリアクセス性能だけの問題ではなく、並列度数が 2 であるための性能低下(もう少し並列度が必要)も含まれている。CG のサイズ B においては並列効率が 2 を超えているが、データ領域が2スレッド計算で二つに分割され、キャッシュがうまく利用された結果、2倍以上の性能値として現れたものである。
PGI コンパイラではこれらのコンパイルにおいて、以下の単純なコンパイラ・オプションのみで、OpenMP のプログラムをコンパイルできる。 -mp オプションが、OpenMP プログラムに対して、マルチスレッドコードを生成するように指示するものである。

  pgf95 -fastsse -O3 -mp xxx.f (pgf77 / pgcc / pgCC も同様)

また、PGI コンパイラ 6.0-5 以降においては、 Linux が提供している NUMA ライブラリ(libnuma.so) を一般的なスレッドライブラリの代わりにリンクする機能を有する。また、それに伴い、コンパイラの最適化機能を改善している。AMD Opteron 等の 2-way 以上の NUMA アーキテクチャのシステムでは、thread-to-CPU スケジューリングのaffinity(親和度)等の機能を有効にするオプションとなります。これを行うためのコンパイル・オプションは、以下のように、-mp=numa と指定すればよい(PGI6.0−5の新機能)。これは、NUMA アーキテクチャに対しても最適化しているPGI コンパイラが提供する機能である。(注意) この機能が有効となる OS は、現在、SuSE 9.2/9.3 and SLES 9 の OS 下のみで可能です。 但し、PGI 6.1 以降では、 numa サブオプションは廃止されました。PGIコンパイラをインストールした時点で、libnumaライブラリを備えたシステムであれば、-Mconcur あるいは-mp の使用時に自動的にリンク(-lnuma)できるようにコンパイラ・システム内部で設定されます。

  pgf95 -fastsse -O3 -mp=numa xxx.f

PGI コンパイラは、「自動並列化機能」も備えている。自動並列化によって、全てのプログラムが性能向上するわけではないが、以下のオプションで自身のプログラムの並列化を行うこともできる。

  pgf95 -fastsse -O3 -Mconcur xxx.f

関連TIPS情報
PGI コンパイラの並列化のためのオプション
NUMAアーキテクチャ上でのスレッド制御を行うためのマルチプロセッサ環境変数」 New!!

Athlon64 X2 4400+ (2.2GHz, 1Mcache) の PGI 6.0 による並列性能
NPB 3.2-OpenMP BT CG EP FT LU-hyper MG SP
SIZE (W) 24x24x24 7000 2^ 25 128x128x32 33x33x33 128x128x128 36x36x36
1 thread (Mop/s) 1528.35 417.55 18.83 620.21 891.96 980.49 848.53
2 thread (Mop/s) 3248.11 688.59 37.75 1106.08 1865.61 1207.56 1228.23
並列効率 2.13 1.65 2.00 1.78 2.09 1.23 1.45
SIZE (A) 64x64x64 14000 536870912 256x256x128 64x64x64 256x256x256 64x64x64
1 thread (Mop/s) 1490.55 330.29 18.81 640.86 623.14 870.58 802.1
2 thread (Mop/s) 2615.37 597.32 37.67 1153.91 1021.94 993.35 1099.3
並列効率 1.75 1.81 2.00 1.80 1.64 1.14 1.37
SIZE (B) 102x102x102 75000 2147483648 N/A 102x102x102 256x256x256 102x102x102
1 thread (Mop/s) 1326.72 121.43 18.81 N/A 588.34 930.74 777.05
2 thread (Mop/s) 2306.09 412.73 37.71 N/A 827.53 1070.80 1012.54
並列効率 1.74 3.39 2.00   -     1.40 1.15 1.30

      使用コンパイラ  : PGI 6.0
      使用コンパイラ・オプション : pgf95 -fastsse -Mipa=fast -mp -Minfo
      BT、SP は、並列プロセッサ数が N2 で行うべきものであるが、ここではあえて 2 スレッドで計算

さて、デュアルコアのシステムではなく、シングルコアの NUMA アーキテクチャを採用する Opteron システムでは、上記の並列化効率がどのように異なるかを検証した。使用したシステムは、一番初期の Opteron プロセッサ(1.4GHz, 1Mcache, 2GB-PC2700・CL3 バルクメモリ)と言う今となっては極めて遅いシステムで性能を測定した。(メモリも遅いことを添えておく)。以下に並列効率のみの数値を表した。
本 Opteron の試験システムのマザーボードのメモリモジュールは、CPU 0 側にのみ接続されたメモリモジュールと言う構成のため、2-wayでありながら、1 メモリコントローラのみで制御される形態となっている。したがって、総合メモリバンド幅は、6.4GB/sec となり、各CPU で直結されたメモリモジュール構成に比べ、半分のメモリバンド幅となる。実質のメモリバンド幅はAthlon64 X2 システムと同じであるが、それぞれのシングルコア Opteron CPU 間の HyperTransport を使用したメモリ転送とメモリコントロールが、Athlon64 X2 デュアルコア・アーキテクチャの挙動より強力であることが伺われる。少なくとも Athlon64 X2 のものより、マルチスレッド並列化効率はかなり向上していることが分かるかと思う。さらに高速なメモリであれば、効率もさらに向上するはずである。なお、使用したマザーボードは、RIOWORKS HDAMB ボードである。
今後、本来の NUMA アーキテクチャである Opteron システムの性能評価も行い報告する予定である。


シングルコア Opteron 2-way (1.4GHz, 1Mcache) の PGI 6.0 による並列性能
NPB 3.2-OpenMP BT CG EP FT LU-hyper MG SP
SIZE (W) 24x24x24 7000 2^ 25 128x128x32 33x33x33 128x128x128 36x36x36
並列効率 2.02 1.88 2.00 1.78 1.96 1.42 1.74
SIZE (A) 64x64x64 14000 536870912 256x256x128 64x64x64 256x256x256 64x64x64
並列効率 1.83 1.69 2.00 1.86 1.88 1.52 1.55
SIZE (B) 102x102x102 75000 2147483648   102x102x102 256x256x256 102x102x102
並列効率 1.83 1.84 2.00  1.82 1.66 1.44 1.56

このように、アプリケーションのメモリアクセスの特性並びにメモリ・アーキテクチャアによって、デュアルコアのマルチスレッド性能は左右される。これはコンパイラの問題ではなく、システムのメモリ性能による問題であることをご理解いただきたい。もちろん、並列化の作りこみにも多分に関係する。

PGI コンパイラは、NUMA/Dual Core の AMD プロセッサだけではなく、インテル社のデュアルコア Pentium D プロセッサのマルチスレッド・コードを生成できます。



この画面トップへ

<< SPECfp2000による性能比較 SSE/SSE2 による最適化性能、OpenMP 性能 >>

※本ページに記載されている会社名、製品名は、各社の登録商標または商標です。

 ソフテックは、PGI 製品の公認正規代理店です

サイトマップ お問合せ
Copyright 2004 SofTek Systems Inc. All Rights Reserved.