今後の主流となるべく、改善が続くIntel Compiler

　

苛烈な性能追求と歴史を背負ったFortranの狭間での格闘

Intel CompilerはC++とFortranの両方がありIA-32とIA-64用のものがリリースされています。さてIntel Compilerは少し以前から販売されていましたが、最近Intel CompilerのLinux版がリリースされて性能が確認されてから、注目が集まるようになってきました。さて、Intel C++に関しては、C++言語はコンパイラと共に成長しており、HPCでの利用はまだマイナーなため、この項では対象としません。かたや、Intel Fortranは、DEC Fortran Compilerを源流に持ち、さらにKAP Fortranの技術も統合され、その血統は非常に優れたものであります。しかしながら、Fortranは科学技術計算目的が主流のためコンパイラの生成オブジェクトに対するの性能要求は強烈なものである一方、言語そのものは長い歴史を背負っていることもあり、性能追求の副作用として古い形式のソースコードでは思いがけないバグが顕在化することが有ります。IA-32、IA-64がハイパフォーマンスコンピューティングの主流となるにしたがってIntel Fortran Compilerも源流であるDEC Fortran Compilerのように『枯れる』プロセスを辿るコンパイラであろうと思います。C++ CompilerとあわせてIntel Compilerは今後 10年間は主軸のFortranであることは確かです。

生き物としてのコンパイラ

優れたコンパイラであるか否かを計る指標として、改善サイクルは良い目安となります。これが遅々として進まないコンパイラは、次第にユーザが離れ朽ち果ててゆくことを意味しています。勢いのあるコンパイラは、どんどん新しいバージョンが公開され、これまでユーザを悩ませていた問題が雲散霧消していることも多く、さらに、性能改善に目を見張ることもあります。言語は生き物であり、コンパイラも時代の中で活発に生きているか否かが重要だということです。

速い改善サイクルの例

さて、Intel Compilerの日々の改良や性能/品質向上例として、プレミアサポートの最新バージョンでは 1GBバイト超えのメモリ確保方法のデフォルト値の変更や、ループ中のwrite文によるディスクボトルネックの問題などが、こっそり解消されている例などを挙げることができ、速いサイクルで細部の改良が続いていることが良くわかります。ここで、「旧来のUNIX WSのコンパイラでないと安心できない」 との心情は食わず嫌いによるものではないでしょうか？ 是非とも弊社のOpen-SCCにてIntel Compilerの味見をなさることをお薦めします。

ユーザからのフィードバックとIntelの資本力が改善の両輪

Linux上のIntel Compilerのユーザ数は瞬く間に商用UNIXマシン上の商用C++や Fortran コンパイラのユーザを上回り、多数のユーザからのフィードバックとIntelの資本力により商用UNIXマシン上の商用コンパイラの何十倍もの速度で進化しています。この改善サイクルの速度は、非常に多くのユーザがコンパイラ改善の一翼を担い、日々の利用での疑問点があればその問題の所在を探り当て、開発者に報告することで改善の参考にしてもらい、一刻も早い解決の実現に協力するからこそ実現できるスピードです。また、このスピードはオープンソースプロジェクトに見られるコラボレーションの仕組みがうまく噛み合っていることを示しています。さらに、Intel Compilerはプレミアサポートという窓口を持っており、オープンソースプロジェクトより厚いサポートの仕組みも備えています。

この開発者にしてこのコンパイラなのだと、その誠実な態度に感心

もちろん、弊社もIntel Compilerにはお世話になっており、改善の依頼を行うことがあり、Intel Compilerの開発者は素早い対応のみならず、時としてその後の状況確認のメールまで受けることがあります。この開発者にしてこのコンパイラなのだと、その誠実な態度に感心いたしました。

なんらかのお役に立てるよう努力したい

また、弊社といたしましても、日々のサポート活動から蓄積した情報のトピックスを、お客さまにWebを通じて提供することを心掛けるようにしております。なにかおかしいなと挙動不振をお感じになられましたら是非、弊社にご質問ください。すべての場合に問題解決を保証できるとは限りませんが、なんらかのお役に立てるよう努力する所存であります。

テスト環境のご提供

しかし弊社としても、全てのお客様のお問い合わせに対処することには限界があります。また、お客様の側も問い合わせの手間などで、見送られる方もいらっしゃることと思います。その対策として、以下の方法をご提案いたします。

コンパイラのバージョン確認方法

バージョンの確認方法は以下の通りです。
ifc -V
と叩くと、バージョンが出力されますので、Buildの日付を見てください。

例えば2003年3月5日現在の最新バージョンは“Build 20030212Z”です。
一般にダウンロードしてセットアップできる2003年3月5日現在のものはicc7-7.0.065、ifc7-7.0.064(Build 20021028)になります。
プレミアサポートにて案内されている2003年3月5日現在の新しいバージョンはicc7-7.0.086、 ifc7-7.0.087(Build 20030212)です。

最新バージョンの入手方法

最新バージョンを入手するには、プレミアサポートに登録して、最新バイナリーをダウンロードする必要があります。プレミアサポートの登録方法は以下の通りです。

下記サイトにアクセスして頂き、
https://shale.intel.com/registrationcenter/register.asp
中央右のnewusersのところにメールアドレスを登録してください。
アカウントを登録後にintelからメールが送信されます。
そのメールにtemporary password があります。
再度、上記のサイトに入って頂き、Log in my Accountをクリックしてください。
IDが登録したメールアドレスとtemporary password でログインしてください。
その後正規のパスワード登録が要求されますので、登録してください。
これで登録終了になります。すると最新のバイナリをダウンロードして利用することが可能となります。

コンパイラ更新の可否の安全な事前確認手段

新しいバージョンのコンパイラをインストールした事で旧バージョンが利用できなくなる不安を持たれ、新バージョンのインストールに二の足を踏まれることは理解できます。しかし、日々更新されるコンパイラの特性を事前に各バージョンにおける挙動や性能の違いまで含めて確認するためには、複数環境を個人あるは小グループ単位で整備する必要があります。ところが、この環境構築は手間がかかります。そこで弊社Open-SCC環境に、主要なバージョンのコンパイラをインストールし、 各バージョンでの挙動や性能の違いを確認できる環境を作成し、広く公開いたします。是非ともプレミアサポートと併せてご活用おねがいいたします。

　

　

「追加情報： Intel Fortranで1GB以上の領域確保について」 (03/05/14)

お客様から以下のような貴重なご意見を頂きました。

> HITのページにあるifcの
> 「 Intel Fortran compiler も C compiler も配列の静的確保で１ＧＢ以上の領
> 域は取れませんが、Fortran の場合ダミーのcommonを使って回避可能です。」
> という記述が気になったのでメール致しました。
>
> commonを使用しなくても、コンパイル時に-staticオプションを付ければ、
> 2.0GBまで使用できると思うのですが、いかがでしょうか？
> 我々は普段このオプションを付けて、1.0GBを越える計算をしています。

そこで早速確認のため弊社技術に実地調査を命じました。

結論から言って、リンクオプション (スタティックリンク/ダイナミックリンク) で確保できる量が変わりました。FORTRANで使う配列を類別すると以下のようになります。

(1) 単純配列
(2) common に割り当てられている配列
(3) common に割り当てらてている配列で、IntelCompiler 拡張で dynamic common の属性がつけられているもの (compile/link 時に　-Qdyncom"foo" といったオプションをつけます。)
(4) FORTRAN90 からの拡張で、allocatable 属性がつけたれたもの

そして、(1)(2)がいわいる静的確保された配列で、(3)(4)が動的確保になります。testプロラムを作成しお客様のご指摘を確認しました。実行モジュールをダイナミックリンクで作成した場合は、870MB足らずしか配列に割り当てることしかできませんが、スタティックリンクにした場合は、お客様が指摘されたとおり、何もせずに合計2GBまで割り当てられます。動的確保でも2GB、プロセス全体（コード領域を含む）で3GBという点は変わりません。以下にtest programのソースコードを添付します。

=== test program ===

program mem_allocation
parameter ( na = 100 )
parameter ( nb = 100 )
parameter ( nc = 520 )
parameter ( nd = 520 )

REAL*8,ALLOCATABLE :: a_buf(:,:,:)
REAL*8 :: c_buf(nc,nc,nc)
REAL*8 :: b_buf(nb,nb,nb)
REAL*8 :: d_buf(nd,nd,nd)

common / bar / b_buf
common / foo / c_buf

print *, na*na*na*8 / 1024 / 1024
print *, nb*nb*nb*8 / 1024 / 1024
print *, nc*nc*nc*8 / 1024 / 1024
print *, nd*nd*nd*8 / 1024 / 1024

allocate ( a_buf(na,na,na) ) 1

continue

do i=1, na
do j=1, na
do k=1, na a_buf( i,j,k ) = i+j+k

enddo
enddo
enddo

do i=1, nc
do j=1, nc
do k=1, nc c_buf( i,j,k ) = i+j+k

enddo
enddo
enddo

do i=1, nd
do j=1, nd
do k=1, nd d_buf( i,j,k ) = i+j+k

enddo
enddo
enddo

do i=1, nb
do j=1, nb
do k=1, nb b_buf( i,j,k ) = i+j+k

enddo
enddo
enddo

goto 1

end

=== end of test program ===

お客様の貴重なご意見により、また有用な一つ情報が増えました。と、ここで終えればスマートなのですが、よくよく確認してみると弊社の技術陣は-staticオプションの事実を知っていた模様です。Web原稿作成担当である社長の元に情報が伝わって来ておりませんでした。今後は、なるべくこのようなことが無いように心がけたいと存じます。 今後とも、お客様からのご意見をお待ちしております。

　

　

「結局、IA-32 Linuxで使えるメモリは？ファイルサイズは？」 (03/04/25)

「Intel Fortran compilerが1GB以上のメモリーを取れない」事件がありましたが、その後もIA-32 Linuxで利用可能なメモリ空間とIntel Compilerで利用可能な配列サイズの問題で多少の混乱をきたしております。その原因の多くはLinuxのKernel 2.2までの制限値とKernel 2.4からの制限値が異なること、さらにIntel Compiler制限値が別にあることが周知徹底されていないことであると判明しました。

.	Kernel 2.4	Kernel 2.2
ユーザID / グループID	約43 億(=2^32)	65536(=2^16)
最大物理メモリ	最大64GB (Physical Addressing Extention: PAE をサポートする IA-32 x86) 最大4GB (上記以外の IA32 x86)	最大2GB
プロセス数	実行時に最大値を設定、メモリの搭載量のみに依存　/proc/sys/kernel/threads-max (実質無制限)	1024
最大ファイルサイズ	ファイルサイズ 論理的には4TB (32-bit アーキテクチャ、現時点ではKernel の制約により2TB まで) ファイルシステム 全体では16TB まで 既存のext2では2TB ※OSに付属しているコマンド/ユーティリティがすべて2GB以上のファイルに対応しているわけではありません。	最大2GB

PAE : (Physical Addressing Extention) インテルはPentium Pro processorからPAEという名称で36-bitの物理アドレス空間を持つ動作モードを実装しています。このモードで動作するシステムでは、最大64GBの物理メモリ空間が利用可能となっています。最近のXeon機では８本程度のメモリソケットが実装されており、2GBのモジュールを８個実装すると、合計16GBのメモリを搭載することができ、OSからはこの16GBのメモリ空間が利用できることを確認しています。布石は打たれているということです。

しかし、現状のIA32用Intel CompilerではKernel 2.4でのPAEをサポートしない一部のマシンのことを考えてなのか、論理アドレス空間は4GBに制限されている模様です。この4GBの中からPCI-Bus等のハー ドウェアへのアクセスのためのアドレスとして1GBを使用していますので、一つのプロセス全体で利用できるアドレス空間は最大3GBです。さらに単一の配列では最大2GBという制限があります。

以下、Intel Compiler IA-32メモリ確保関連の実地調査結果です。

(1) ifc

単一の配列で2GB以上のものを切ろうとするとコンパイル時に

Error 530 : In program unit MAIN.PROGRAM the size of array A_BUF exceeds
the implementation limit (2**31-1)

実行時にstaticの配列が合計３ＧＢ弱を越えると

** Address Error **
End of diagnostics

dynamicの配列の合計が３ＧＢ弱を越えると

Allocate Common Error 475: Allocation Failure

The allocation of dynamic common AAA of size 1728000000
in procedure main program failed

End of diagnostics

合計最大３ＧＢ弱です。

(2) icc

動的配列でも単一配列で２ＧＢが上限、合計で３ＧＢ弱はFORTRAN と同じです。

　

　

「Intel Fortran compiler7.1が、再バージョンアップ」 (03/04/11)

03/04/11現在、たった２日で更に更新されています。変更箇所の確認と動作検証は引き続き行っています。お客様の更新は、もう少しの期間、様子をみてからでも良いかもわかりません。
C : l_cc_pu_7.1.011.tar
Fortran : l_fc_pu_7.1.013.tar

　

「Intel Fortran compiler7.1が、早速バージョンアップ」 (03/04/10)

最近公開されたインテルコンパイラ V7.1 が最近マイナーバージョンアップしました。動作検証はこれからですが、ドキュメントの
Q176388 random numbers always are same
Q173458 problem with random seed and random number generator
あたりを考えるとバージョンアップは必須だと思われます。また、前バージョンで少し落ちたパフォーマンスが再び戻っていることを期待したいところで、検証作業を行っています。

最新バージョンにアップデートするには、 Ver 7.1 のオリジナル
l_fc_p_7.1.008.tar
インストール後、パッチ
l_fc_pu_7.1.011.tar
をインストールする必要があります。

4/10 現在新規のプレミアムサポート登録者には Ver7.1オリジナル（l_fc_p_7.1.008.tar）
http://www.intel.com/software/products/compilers/downloads/clin.htm
がダウンロードできるようになっています。

このパッチはプレミアサ ポートに登録の上ダウンロードする規約になっています。最新バー ジョンの確認方法は 「-V」オプションを使います。
% ifc -V
Intel(R) Fortran Compiler for 32-bit applications, Version 7.1 Build　 20030327Z
Build番号が 20030327Z になっていれば成功です。

また、一般向けバージョンも V7.1 で公開されました。さきにも書きましたように最新の「Intel(R) Fortran Compiler for 32-bit applications, Version 7.1 Build　 20030327Z」を利用するためには、まず一般向けバージョンの V7.1が必要です。これは
http://www.intel.com/software/products/compilers/downloads/clin.htm
http://www.intel.com/software/products/compilers/downloads/forlin.htm
でダウンロード可能です。

　

「Intel Fortran compilerが1GB以上のメモリーを取れない」事件 (03/03/10)

このたび、弊社システムを複数回に渡って導入いただいているお客さまから「新規導入のシステムでIntel Fortran compilerが1GB以上のメモリーを取れない、この件に関する回答がはっきりしないので既存のシステムでの計算結果にも疑義を挟まざるを得ない。」との趣旨のご質問を受けました。さらに調査の課程で「導入時期の異なるシステムでifcでコンパイルした1GB以上のメモリを確保するプログラムの動作が異なる。」という問題が発生しました。

結論として、ifcのメモリ領域確保のデフォルトがVer.5までとそれ以降が異なっていることが原因でした。

Ver.5 　
・ifcのバージョンが5.0.1だとcommonであるなしにかかわらずC言語でいうmallocによって変数が確保されます。
Ver.6, Ver.7
・通常の変数として使える領域はプログラムを含めて1GB以下です。
・そうでない変数、common宣言をし1配列が128KB以上かつ-Qdyncomコンパイルオプション指定したものであるが、これは2GBまで使えます。

ifcのメモリ領域確保のデフォルトがVer.5までとそれ以降で異なるのは、変更によって一般的な他のFortranコンパイラと動作を合わせるためです。プログラムのメモリの確保には静的領域確保と動的領域確保があります。非常に昔のFORTRAN IV（FORTAN77の前のFORTAN66のさらに前、FORTRANの規格が無かった頃）というコンパイラでは
・ common文に書かれたデータ
・ save文に書かれたデータ
・ 初期値ありデータ
を静的領域に確保し、common文の初期値がゼロに設定されるようになっていました。 したがって古いプログラムではこの静的領域確保されたデータがゼロで初期化されることを期待しているものがあり （現在のFortran規格では規則違反）、こういったプログラムで問題が生じる報告が多数なされたためIntelはデフォルトの動作を変更したものと思われます。
IntelとしてはVer.5の頃はメモリがたくさん利用できる方が良い、オプションで古い慣習をサポート出来るのでよいだろうと判断したのでしょうが、市場は古いプログラムをデフォルトでサポートするように要請したのではないでしょうか。

UNIXプログラムではこのメモリ確保が「セクション」と言う単位でメモリの確保が行 われます。
このセクションは「size」コマンドによって知ることができます。一例としてperlを見てみます。
$ size /usr/bin/perl
text data bss dec hex filename
690619 31776 2488 724883 b0f93 /usr/bin/perl
「text」「data」「bss」がセクションで、「dec」「hex」はtext、dataは初期値の有る物用の領域確保のためのセクションであり、bssは初期値の無い物用の領域確保のためのセクションです。このdataセクションにIntel Fortran Ver.6以降は
・ common文に書かれたデータ
・ save文に書かれたデータ
・ 初期値ありデータ
を置くようにし「-Qdyncom」オプションとcommon名を指定することでbssセクションに置く （Ver.5までの動作） ように変更になりました。

お客さまとの対話からこのような重要なことが判明しました。弊社では既存納入システムやOpen-SCCでの皆様および弊社の経験から、このようにお客さまとの対話によって判明したことはできる限り公開しハイパフォーマンスコンピューティングコミュニティに貢献して行く所存です。

　

「Intel Fortran compilerが1GB以上のメモリーを取れない」事件経過のご報告

以下、ドキュメンタリー風に今回のお客さまとの対話をご報告します。

（お客様　２００２年１２月９日）
先日お納めいただきましたP4,2.66GHz,2GB x 4 のマシンについてお教えいただき たいことがあります．ユーザーの一人が mpif90 を使い各ノード毎のメインメモリー2GBを出来るだけフルに使った計算をしようとしています．しかし，どうも，1GBを超えた配列が取れないようなのです．なにかコンパイル時のオプションや設定ファイルに必要な記述等ありましたらお教えください．また，このユーザーが，2GBを超えたファイル操作を計算で行いたいのだそうです．ひょっとすると，OS 自体の限界かもしれませんが，2GB を超えたファイル操作が可能なのかどうか，お教えください．以上２点，お力をお貸しください．よろしくお願いいたします．

（弊社サポート　２００２年１２月１０日）

Intel fortran compiler も c compiler も配列の静的確保で１ＧＢ以上の領域は取れませんが、fortran の場合ダミーのcommonを使って回避可能です。以下にサンプルを示します。

% cat bar.f
PARAMETER (NDIM=125000000)
common /foo/ WTAU
REAL(8):: WTAU(NDIM)
WTAU=0.0
STOP
END
% ifc -Qdyncom"foo" bar.f
% ./a.out
%

※上記のようにコンパイル時に common が動的確保であることを指定する必要があります。
※※この方法を用いても2GB以上の配列は確保できません。
よろしくお願いします。

（お客様　２００３年１月２３日）

先日納めていただいた IASD についてユーザーの一人から以下のような質問がありました．以下に示したプログラムをコンパイルして実行しようとしても実行できないのだそうです．

program test
implicit double precision(a-h,o-z)
parameter(m=250 000 000)
real(kind=8) a(m)
do i=1,m
a(i)=dble(mod(i,98))/dble(m)
enddo
x=dot_product(a,a)
write(6,*) x
write(6,*) huge(m)
write(6,*) m
write(6,*) 2**28-1
end

しかし，これを 2001年11月に納めていただいた HPC-P4L/2.0-2048 でコンパイルした実行ファイルをIASDに持ってきて実行させると動くのだそうです．一番の環境の違いといえばインテルfortranコンパイラのバージョンの違いが挙げられます．しかし，私には，この問題の原因はわかりません．解決策をお教えください．よろしくお願いいたします．

（弊社サポート　２００３年１月２３日）
下記のプログラムは約1.9GBの配列を使用するようです。昨年末同様のお問合せで回答していますように、Intel fortran compiler も c compiler も配列の静的確保で１ＧＢ以上 の領域は取れませんが、fortran の場合ダミーのcommonを使って回避可能です。（ただし、2GB以上の配列は確保できません） 以下にサンプルを示しますので試して頂けるでしょうか。 （なお、過去のバージョンのコンパイラでも同様のはずなので、2001年11月納入のマシンでコンパイルした実行ファイルは実行できたというのは解せない点があります。。。）

% cat bar.f
PARAMETER (NDIM=125000000)
common /foo/ WTAU
REAL(8):: WTAU(NDIM)
WTAU=0.0
STOP
END
% ifc -Qdyncom"foo" bar.f
% ./a.out
%

※上記のようにコンパイル時に common が動的確保であることを指定する必要があります。
※※この方法を用いても2GB以上の配列は確保できません。

（お客様　２００３年１月２４日）

HITサポート様の回答によるとifcもIntel C compiler（icc）も配列の静的確保で１ＧＢ以上の領域は取れませんとのことですが，
HIT のホームページ
http://www.hpc.co.jp/hit/IA-Dev/IADEV-ifc.htm
さらには
http://www.hpc.co.jp/hit/IA-Products/P4Linux01-bench.htm
によると（以下HITのホームページから引用）
----------------------------------------
IntelFortranCompiler(ifc)の恐るべき機能
ifcを使えば2GBのメモリをFortranプログラムに何の修正を
加えることなくすべて使える
----------------------------------------（引用終わり）
とあります．
これまでこれを信じてHITのシステムでの計算を行ってきました．HITサポートＡ様からこれを否定する回答をいただいたため当方の利用者がこれまで得てきた計算結果の信頼性を見失いとても不安になっています．そこで，ifc のメモリー使用について何が出来て何が出来ないのか正確に知りたいと思います．今後の既存計算機資源の運用および新規の 　導入計画にも，大きく影響しますので是非，ご回答いただきたいと存じます．

（弊社技術　２００３年１月２４日）

ifcが世に出た頃、common配列はデフォールトでダイナミックにアロケートされました。つまり、common配列なら、無指定で2GBまで確保できました。1GBを超える領域確保を確認しましたが、当時はメモリ供給の問題もあり2GBいっぱいに使えるかは確認しておりませんでした。
当時、姫野ベンチで確かめたので、昔のwebに
> ----------------------------------------
> IntelFortranCompiler(ifc)の恐るべき機能
> ifcを使えば2GBのメモリをFortranプログラムに何の修正を
> 加えることなくすべて使える
> ----------------------------------------（引用終わり）
という文章が載っているのは、その事実が元になっています。

（弊社技術追加報告　２００３年１月２４日）

社内で配列の静的確保で１ＧＢ以上の領域を取るテストプログラムを作成し検証したところifcに-Qdyncomオプションをを付けないと実行時にSegmentation faultを起こすことが確認できました。この動作は現在のifcのマニュアル通りになっています。したがって現在の結論は以下のようなものだと思います。
2003年1月24日時点では、
> ----------------------------------------
> IntelFortranCompiler(ifc)の恐るべき機能
> ifcを使えば2GBのメモリをFortranプログラムに何の修正を
> 加えることなくすべて使える
> ----------------------------------------（引用終わり）
は間違いです。
しかし、これをもってして、
> これまでこれを信じて HPC-P4L/2.0-2048 での計算を行ってきました．
> HITサポートＡ様からこれを否定する回答をいただいたため当方の利用者が
> これまで得てきた計算結果の信頼性を見失いとても不安になっています．
とお客様の懸念がありますが、これまで実行できたプログラムの信頼性を損なう物ではありません。なぜならば-Qdyncomを指定しないで1GB以上の領域を使おうとするプログラムをコンパイルすることはできますが、実行時にSegmentation faultを起こします。したがってこれまで-Qdyncomを指定しなくても実行ができたプログラムは、1GB以上の領域を必要としていなかったと考えられます。実行できたすべてのプログラムの計算結果は （アルゴリズムが正しいとして）正しいと考えられます。

お客様、メモリ使用状況について確認をお願いできますでしょうか？
なお客様の以下の疑問点ですが
> 　そこで，ifc のメモリー使用について何が出来て何が出来ないのか。
以下のような回答となります。
・通常の変数として使える領域はプログラムを含めて1GB以下である。
・そうでない変数、common宣言をし1配列が128KB以上かつ-Qdyncom コンパイルオプション指定したものであるが、これは2GBまで使える。

（お客様　２００３年１月２５日）

現状でのifcで１ＧＢ以上の配列の静的確保で利用したプログラムがそもそも実行できないことがわかりました。したがって当方でこれまで実行できたプログラムの結果に問題が無いことも納得しました。ということは当方でこれまで実行したプログラムは1GBを超えていない可能性があるので調べてみます。

（お客様　２００３年１月２７日）

先日からお尋ねしている1GBの壁越えの問題について、新たな問題が発生したので検証していただけませんか。当方でも１ＧＢ以上の配列をダミーcommon文を使わずに静的確保をするサンプルプログラムを作成し実行したところ納入時期の異なるシステムで挙動が異なることを発見しました。

・2001年11月納入システム
コンパイルオプション無指定でコンパイルして実行しますと実行できてしまいます．また結果も正しいようです。

・新規導入システムおよび2002年11月納入システム
同一ソースをコンパイルして実行させようとしますとSegmentation faultで異常終了してしまいます。ところが2001年11月納入システムで作成した実行オブジェクトは実行できて結果も正常です。

一体何が起こっているのでしょうか？
現象の解明をお願いします。

（弊社サポート　２００３年１月２７日）

納品した時期により、同じプログラムなのに動作が異なるという件ですが、前回の回答の中で説明が不足していました。2001年11月に納入システムに導入したifcの初期のもので、-Qdyncomオプションがデフォールトでオンになっていると考えられます。現在のコンパイラのでは、-Qdyncomオプションがデフォールトでオフです。上記の変更がいつから行なわれたのかは、現在のところ弊社では確認できていません。
なお、コンパイラのバージョンは
% ifc -V
のコマンドで確認できます。
従いまして以下の状況はそれぞれのシステムに導入されたifcのバージョンのデフォルトの差異から生じる現象であると思われます。
>　・2001年11月納入システム
>　コンパイルオプション無指定でコンパイルして実行しますと
>　実行できてしまいます．また結果も正しいようです。
> 　
>　・新規導入システムおよび2002年11月納入システム 　
> 同一ソースをコンパイルして実行させようとしますと 　
>　Segmentation faultで異常終了してしまいます。 　
>　ところが2001年11月納入システムで作成した実行オブジェクトは 　
>　実行できて結果も正常です。

（お客様　２００３年１月２８日）

新たな問題が生じました．2002年11月納入のクラスター機で先日のサンプルプログラムをifc でコンパイルし実行しますとSegmentation faultと異常終了します。しかし，同じマシン上で mpif90 を使って何もオプションをつけずにコンパイルし実行しますと動作し正しく計算してくれるようです．このmpif90 が生成した実行オブジェクトは新規導入システムでも 正常動作します。何が起こっているのでしょうか？

（お客様　２００３年１月２８日追加）

ifc -V　で得られた表示をお知らせいたします．
Intel(R) Fortran Compiler for 32-bit applications,
Version 5.0.1 Build 010730D0
Copyright (C) 1985-2001 Intel Corporation. All rights reserved.

（弊社技術　２００３年１月２８日）

ifcのバージョンが5.0.1だとcommonであるなしにかかわらずC言語でいうmallocによって変数が確保されることが判明しています。

（お客様　２００３年１月３０日）

精密な調査と明快なご回答ありがとうございました．
大変な作業だったと思います．
重ねて感謝いたします．
ありがとうございました．
早速，ユーザーに，この回答を知らせます．
お骨折りありがとうございました．

最後にはこのように暖かいお言葉をお客さまより頂戴し弊社サポート、技術陣ともも一層の努力と研究開発、経験蓄積に邁進する念を強く抱きました。

　

　

　

ifc 7.0 テスト速報 (02/12/06)

Intel Fortran Compiler 7.0がリリースされ、改良が続いています。これにより、使いやすくなったり性能も向上しているのですが、そのなかでも興味深い「OpenMP/Autoparallel」対応と「Multi-Threaded Application Support」をXeonやHyperThread対応の3.06GH Pentium4で試しています。

Multi-Threaded Application Support:

* OpenMP support: OpenMP is the industry standard for portable multithreaded application development, and is effective at fine grain (loop level) and large grain (function level) threading. The Intel Fortran Compiler supports the OpenMP* Fortran version 2.0 API specification (except WORKSHARE OpenMP directive) and performs code transformation for shared memory parallel programming. The Intel Fortran Compiler supports multi- threaded application development and debugging, with OpenMP 2.0 for Fortran.

* Auto-Parallelization: The Intel Fortran Compiler 7.0 includes an Auto- parallelization feature for automatic threading of loops. This feature provides developers with an easy way to take advantage of parallelism to improve application performance on multiprocessor systems. It detects parallel loops capable of being executed safely in parallel and automatically generates multithreaded code for these loops. Automatic parallelization relieves the user from having to deal with the low-level details of iteration partitioning, data sharing, thread scheduling and synchronizations. It also provides the benefit of the performance available from multiprocessor systems and systems that support HyperThreading technology.

　

Hyper Threading を使うには ifc 7.0 が必須

前回 12月5日にifc 7.0が並列実行時にCPUリソースを開放するという報告を行いましたが、それをHyperThreading対応機上でも検証しました。まず比較のため、前回と同じプログラムをHyperThreading上で実行してみます。OpenMP/Pentium4向け最適化で実行すると、

ifc6: 231.87user 0.42system 1:59.89elapsed 193%CPU
ifc7: 156.35user 18.01system 1:42.96elapsed 169%CPU

となります。なおテスト機はXeon 2.8GHz 1CPU(HyperThread 対応) 2thread です。

CPUの利用率はSMPの時と同様にifc Ver6.0では193%とふたつの仮想CPUをほぼ使いきり経過時間は1:59.89かかっています。一方、ifc Ver7.0ではHyper-ThreadingによりCPU内の演算器を効率良く使っているため169%の利用率で、経過時間が1:42.96と16%の性能向上が見られます。

ここでHyperThreadingについて再確認します。HyperThreadingでは1つの実行リソース(物理的なCPU)を共有しながら2つ仮想的なCPUが存在するとして、threadレベルの並列処理を実現する技術です。Pentium4/Xeon NetBurstアーキテクチャでは2倍速で動作する算術演算装置（ALU、整数演算や浮動小数点を行う）が2個存在すると考えると、9つもの実行ユニットが存在することになります。そして20段パイプラインを持ちますので、9×20で180段・個の実行ステージがあることになります。

・ out-of-order実行にともなうロス
・ 分岐予測エラーにともなうロス
・ キャッシュミスにともなうロス

などが発生すると180段・個の実行ステージの多くが何もしない命令(NOP)で埋められることになります。
HyperThreadingでは、別々のthreadに属する演算を重ねることで1つのthreadが発生させたロスによる空き実行ステージに、もう1つのthreadの演算を埋め込むことで、実行ユニットすなわちCPUの利用効率を上げます。したがってHyperThreadingでは

・ 実行ユニットの利用効率の悪い処理同士を同時に扱う
・ 同一プロセスに所属するスレッドを実行する

場合などに大幅な性能の向上が期待できます。これを非常に簡略化した例で説明します。整数演算ユニット（IU）2つ、浮動小数点演算ユニット（FU）2つがあるとします。ここで整数演算(１クロック)に依存する浮動小数点演算(２クロック)を行うプログラムが動作するとします。

非HyperThreading
プロセス１：■
プロセス２：●

.	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
IU1	■	.	.	■	.	.	■	.	.	■	.	.	■	.	.
IU2	.	●	.	.	●	.	.	●	.	.	●	.	.	●	.
FU1	.	■	■	.	■	■	.	■	■	.	■	■	.	■	■
FU2	.	.	●	●	.	●	●	.	●	●	.	●	●	.	●

HyperThreading
プロセス１スレッド１：■
プロセス１スレッド２：□
プロセス２スレッド１：●
プロセス２スレッド２：○
仮想プロセッサ（IU1'、IU2'、FU1'、FU2'）

.	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
IU1	■	.	.	■	.	.	■	.	.	■	.	.	■	.	.
IU2	.	●	.	.	●	.	.	●	.	.	●	.	.	●	.
FU1	.	■	■	.	■	■	.	■	■	.	■	■	.	■	■
FU2	.	.	●	●	.	●	●	.	●	●	.	●	●	.	●
IU1'	□	.	.	□	.	.	□	.	.	□	.	.	□	.	.
IU2'	.	○	.	.	○	.	.	○	.	.	○	.	.	○	.
FU1'	.	□	□	.	□	□	.	□	□	.	□	□	.	□	□
FU2'	.	.	○	○	.	○	○	.	○	○	.	○	○	.	○

実際には物理的に実行リソースが倍あるわけではないので速度が２倍になることはありません。物理的な実行リソースの占有状況は以下のようになります。

.	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
IU1	■	.	○	■	.	□	■	.	○	■	.	□	■	.	.
IU2	□	●	.	.	●	.	.	●	.	.	●	.	.	●	.
FU1	.	■	■	□	■	■	○	■	■	□	■	■	○	■	■
FU2	.	□	●	●	○	●	●	□	●	●	○	●	●	□	●

１５クロックでの実行演算数をまとめると以下のようになります。

.	整数演算	浮動小数点演算
非HyperThreading	10	9.5
HyperThreading（仮想）	20	18
HyperThreading（物理）	16	14

この例では、浮動小数点演算を基準に比較すればHyperThreading（物理）は非HyperThreadingに対して14/9.5=1.47倍高速になるわけです。なおHyperThreading（仮想）は非HyperThreadingのSMPでの2CPUに相当するわけです。あくまでも1CPUでHyperThreadingを利用するということは空きステージを使うわけですからおのずと速度向上に限界があります。繰り返しになりますが、

・ 実行ユニットの利用効率の悪い処理同士を同時に扱う
・ 同一プロセスに所属するスレッドを実行すると言う条件が整わなければHyperThreadingの効果が出ません。

ifc Ver7.0ではifc Ver6.0と比較して、自動並列化やOpenMPへの対応強化とそれに伴う最適化機能の強化により上記の条件を満たすコードを掃き出すように改良されているわけです。

最後にCPU利用効率が上昇しているのにサンプルプログラムの実行例

ifc6: 231.87user 0.42system 1:59.89elapsed 193%CPU
ifc7: 156.35user 18.01system 1:42.96elapsed 169%CPU

でCPUの利用率が低いのは、実際のプログラムではキャッシュやメインメモリへのアクセス等の影響があるからです。HyperThreading対応CPUであっても演算器からメモ リへのデータ転送バンド幅は増えていないため待ちが発生するからです。このようなトレードオフがあるためIntelの発表でHyperThreadingの効果は25%から 30%の速度向上が期待できるとなっていると思われます。

ここで再度確認しますと、

・ ifc Ver6.0ではHyperThreadingを活かしきれない。
・ ifc Ver7.0ではスレッドの実行効率を上げるためのthread migrationの機能が強化されている（HyperThreadingに限らない）。
・ ifc Ver7.0ではスレッド対応強化に加え、HyperThreadingに対応しているため仮想2CPUを活用し１つのCPUパワーをスレッドレベルで効率良く利用できる仕組みとなっている。

　

　

ifc 7.0 テスト速報 (02/12/05)

ifc 7.0ではOpenMP2.0対応、自動並列化、ベクトル化が可能になりました。

OpenMP/Autoparallel対応は、ifc Ver6.0のころからありましたが、

% ifc -O3 -xW -axW -tpp7 -openmp xxx.f

と、OpenMP用のソースプログラムをコンパイルしても

ifc: Command line warning: openmp requires C style preprocessing; fpp level is reset to 2

となってしまい、最適化レベルが落ちてしまいます。Pentium4指定をしてもベクトル化されることはありませんでした。ところが、ifc Ver 7.0になってこれが解決されたようです。例えば、Xeon 2.8GHz SMP (HyperThread ではありません）

ifc6 : 147.90user 0.83system 1:18.03elapsed 190%CPU
ifc7 : 102.02user 15.91system 1:13.16elapsed 161%CPU

※1 PGIコンパイラを含め、V6.0までのifcでコンパイルした実行モジュールをmulti threadで実行させると、1CPUでしか実行しない部分でも複数のCPUを掴みつづけます。一方最新のifc V7.0では必要の無い場合はCPUリソー スを開放できるようです。上の二つのuser time/CPU利用率の結果の違いはそこから現れます。計算機環境を最大限に利用するため一度に１プロセスしか実行 しないような場合は関係しませんが、２プロセス以上を一度に実行させるような過負荷状態では、この開放されたCPUリソースを他のプロセスが有効活用できることになります。

※2 上の計算例では比較的小規模な計算を実行しているのでベクトル化を含めた効果はelapsed timeで5秒程度しか現れていません。

※3 LINUXカーネルではthreadのCPU切り替えのオーバーヘッドがあるため、一般的に他の商用ＵＮＩＸ系OSより並列効率が良くありません。

逆に V6.0 の時はPentiumIII向け最適化の方が多少速かったです。

% ifc -O3 -xK -axK -tpp6 -openmp xxx.f

ifc6 : 142.97user 0.80system 1:15.49elapsed 190%CPU
ifc7 : 113.46user 14.82system 1:18.32elapsed 163%CPU

autoparallel の方を同じOpenMP向けソースに適用すると

ifc -O3 -xW -axW -tpp7 -parallel xxx.f

ifc6 : 156.02user 0.64system 2:34.54elapsed 101%CPU
ifc7 : 101.65user 15.31system 1:56.94elapsed 100%CPU

同じく、pgf90では

pgf90 -fast -tpp7 -Mvect -mp xxx.f

pgf90 : 204.82user 0.31system 1:42.98elapsed 199%CPU

※pgi の方は昔からベクトル化可能です。

ifc は環境変数 OMP_NUM_THREADS を指定しなくてもデフォルトで自分のCPU数を数えてthreadを作るが、pgi のほうはちゃんと指定しないとthreadをつくらない。 （逆にifcの方は勝手にthreadをつくってしまうので、1CPUで実行したいときは １ を指定しなければならない) 。

　

ますます期待できる次版のIntel Fortran Compiler (ifc) <02/03/01>

次期バージョンのIntel Fortran Compilerでは以下の機能がサポートされることになっております。

まだ一般には未公開です。早い時期の公開が広く待ち望まれる優れた環境のようです。公開されましたら、大きく速報いたします。

・Streaming SIMD Extensions（SSE）のprefetchをサポート
・-parallelオプションによる自動並列化
・ダイレクトアクセスファイルで2GB超えをサポート
・Fortran95の全機能をサポート
・VAX構造体, CRAYポインタ, Sun IEEE FLAGS関数, タイミング関数（ETIME、 SECNDS）のサポート

SSEのprefetchサポートがメモリアクセス性能の向上を実現し、1プロセッサで3GFlops 超の実効演算性能を達成しました。
-parallelオプションによる自動並列化は2プロセッサで6GFlops弱の驚異的な性能を実現しました。

　

ダイレクトアクセスファイル2GB超えのサポート

ダイレクトアクセスファイル2GB超えのサポートにより、GAMESSなどの Fortranのダイレクトアクセスファイルを利用するプログラムでの2GBファイルの壁を解消しました。プロセス当たりの2GBメモリ空間超えと、ダイレクトアクセスファイル2GB超えにより、ローエンドからミドルエンドの64bit RISC ワークステーションはますますHPC分野では肩身が狭くなって行きます。

　

並列処理環境の向上

NetBurstアーキテクチャに自動並列化機能を実装した優秀なコンパイラとスレッド並列化されたMath Kernel Libraryの組み合わせは本年のHPC分野に旋風を巻き起こすこと間違いありません。これではeon P6(2way-SMP, 8GB-RAM)、Xeon QH(4way-SMP, 4way-16GB-RAM)による市場席巻への要ともいえる布石であり、OSや開発環境まで整合性の取れた準備が着々なされています。Alpha LinuxマシンもTru64マシンの存在を脅かさないようにCompaq Fortran for Linux Alphaから自動並列化機能を除外していた視野の狭さによって窮地に立たされることとなります。

　

息の永そうなNetBurstアーキテクチャ

IntelはIA-64が熟するまでは、現実的な戦略としてNetBurstアーキテクチャへの投資を継続してゆくと思われます。最近の発表では2003年後半には4GHzのPentium4が出荷できるとして、4GHz動作の試作機が公開されていました。この資金力に支えられた開発の底力がIntelの凄みです。米国ではIA-64による巨大なシステムが構築されていますが、これには惑わされてはなりません。これは米国政府による開発援助で行われており、青いIA-64を一刻も早く熟させるためのサポートプロジェクトです。一般の堅実なHPCシステム利用者は現実に性能が確認されている範囲内での最新システムを購入することが大切です。より良いシステムが登場すれば乗り換えればすむ話です。そのためにも特定のアーキテクチャに依存 しないオープンな姿勢がなによりも肝要です。

　

　

ifc6.0Beta + MKLのMatM(行列積テスト)でDual Xeon2.2GHz : 5.9GFLOPSを記録、
あまりの素晴らしさに言葉も出ません。<速報 02/02/25>

　

Open-SCC内のXeon2.2GHz機でMatM行列積テストを最新のifc6.Beta +MKL環境で実行したところ、1000 x 1000で最大値5890Mflopsを記録しました。これはPentium4、XeonのNetBurstアーキテクチャがHigh Performance Computing性能をいよいよ顕在化させた確証になります。すなわち、Intel Math Kernel Library(MKL)やATLASといった基本数値演算ライブラリがNetBurstアーキテクチャに先行的に最適化され始めたということです。さらに今後、IMSLやNAGライブラリなどの一般的な数値演算ライブラリがNetBurstアーキテクチャに最適化された時のことを考えるとワクワクします。なぜなら、Alphaでの経験から、新しいアキテクチャのCPUが登場してから一年ほどのタイムラグをおいて開発環境が成熟することを知っているからです。Pentium4 (NetBurst)が発売されたのが2000年11月ですから早くも15ヶ月が経過し、ようやくその真価を顕在化させてくれました。

以下のMatM Testのグラフを見ると前回の現行版IFC + MKL or +ATLASでは200と400にピークが見られます。これは測定誤差か、あるいは問題サイズと搭載キャッシュとのマッチングによるマジックナンバー的な性能ピークと思われます。

　

　

従いまして、このような突出した値が存在する測定値を比較するには、算術平均(Average)ではなく、幾何平均(Geometric mean)を用いなければなりません。これは以下に表にまとめました。

CPU	Clock	Cache	Compiler	Lib	Geo. MFlops	Ave. MFlops	Note
Alpha EV67	833MHz	4MB	Compaq fort	CXML	1358	1364	.
Pentium4	2.0GHz	256KB	IFC	MKL	2329	2429	.
Pentium4	2.0GHz	256KB	IFC	ATLAS	1930	2015	.
Athlon	1.2GHz	256KB	IFC	ATLAS	1434	1451	.
Athlon	1.2GHz	256KB	PGI	ATLAS	1390	1401	.
Xeon	2.2GHz	512KB	IFC 6.0beta	MKL	2782	2811	1 thread
Xeon	2.2GHz	512KB	IFC 6.0beta	MKL	4874	4946	2 threads
Pentium4	2.2GHz	512KB	PGI 3.3-1	ATLAS	2559	2571	.

Pentium4 2.2GHz 512KB+PGI 3.3-1+ATLASとXeon 2.2GHz 512KB+IFC 6.0beta+MKL (1 thread)を比較すると、まずはIntelのMKLがNetBurstアークテクチャに対して熟成が進み、ATLASも良い線までいっていることが分かります。

しかし、今回特筆すべきはなんといってもXeon 2.2GHz 512KB+IFC 6.0beta+MKL (2 threads)の大きな躍進です。マルチスレッドにおいて資源競合により性能低下が顕在化する可能性が有る100、200、300と言った行列サイズが小さなところから1000までの大きなところまで、右上がりに性能が向上しており、このシステムの真価が顕在化してきたことを如実に示しています。今後はHyperThreadingが性能向上に貢献し始めることが予想され、数値演算ライブラリやコンパイラ、アプリケーションコードのNetBurstアーキテクチャへの対応が進めば他のアーキテクチャを圧倒することは間違ありません。その先鞭をつけるのがこの行列積ベンチマークです。

これにたいして、NetBurstアーキテクチャの半分以下の相対性能となり、今となっては見る影もなくなってしまったのがAlpha21264/833MHz機です。Alphaのポジションがこのようになったのですから他のRISC機も同様です。

またAthlonは、Windowsでの利用は雑誌などが評価する仕事なので措くとして、HPC分野においてはコンパイラやアプリケーションの対応がNetBurstアーキテクチャに対して一周遅れ気味で、ようやくAlpha21264レベルに到達したということが判ると思います。ここは非常に大きな問題を孕んでいるので敢えて苦言を呈しておきますが、主にゲーム用途のベンチマークテスト結果をもとに、HPCでも有効そうな表現を雑誌等でいまだに見かけることがあります。この混同はHPC分野での正確な判断を妨げてしまう可能性があります。また、IA32をHPCで利用しようということでAthlon (PentiumIII)でベンチマークを行っても、それでは最新のIA32アーキテクチャの評価とはなり得ません。

テストに利用した MatM公開コード はソースコードを公開しています、是非ともシステム測定用にご利用なさってください。

　

　

ifc6.0Beta の特性がHR CacheMemory Test でも良くなっていることを確認 <速報 02/02/25>

引き続き、高解像度版のキャッシュメモリテストでの効果の確認を行ってみました。注目は青太線Xeon2.2GHzと赤太線Xeon2.2GHzのキャッシュ領域の特性の平坦さに大きな違いが現れています。

　

　

ifcの日本語版マニュアルが無償でダウンロード可能

以下のサイトでIntel Fortran Compiler 5.0の日本語版マニュアルが公開されており、メールを送ると無償でダウンロードができるようになります。

http://www.xlsoft.com/jp/products/vtune/download.html

　

　

Gaussian98のifcビルドがすばらしい成績 <速報 10/1>

フラッグシップ級の並列サーバや最新のスパコンが競い合う領域で、弊社チューニングのHPC-P4Lは互角に渡り合う性能を示しています。また、「電子構造論による化学の探究」全例題と全てのテストジョブを実行し、Alpha-Linux水準のビルド完成度がおおよそ確認できています。テストの詳細についてはIA32-Gaussianの項を参照お願いします。

System	CPU	並列	CPU数	g98 cpu time (sec)
				test415
VPP5000	9GFLOPS	-	1	2,408
P4L/2.0 (A10 IDE_HDD)	Pentium4/2.0GHz	-	1
UP264/833FF-1024U	Alpha21264/833MHz.	-	1	2,853
Origin2800	R12000-300MHz	yes	8	7,384

　

System	CPU	並列	CPU数	real time (sec)
				test397
Origin2800	R12000-300MHz	yes	8	8,022
VPP5000	9GFLOPS	-	1	14,003
P4L/2.0 (A10 IDE_HDD)	Pentium4/2.0GHz	-	1
UP264/833FF-1024L	Alpha21264/833MHz.	-	1	24,890
IBM9076 SP2	Power2	yes	8	27,042

　

AMBER6のifcビルドも良い成績 <速報 9/28>

並列計算を行う場合、ノード数の増加は計算時間の短縮を意味しますが、それは同時に通信時間の増加をも意味します。その比率は計算に依存しますが、それにしてもトードオフの関係にあることは確かです。

AMBER6など通信時間の比率が大きいアプリケーションで絶対性能を向上させるには、高速なCPUを用いノード数を少なくするシステム設計が大切です。そのためAMBER6テストは意味があります。今後も網羅的にテストを行ってゆきます。

System	CPU	Clock (MHz)	CPU	OS	Nerwork	Nerwork	AMBER6 Prowat sander (sec)
O2000	R10000	250	8	.	.	.	34 (est)
UP264/667FF	21264	667	4	SuSE	Myrinet	Mpich-ch_p4	64.9
P4L/2.0 (ifc)	Pentium4	2.0GHz	1	SuSE	-	-	74.0
P4L/2.0 (PGI)	Pentium4	2.0GHz	1	SuSE	-	-	85.9
IAX/1.7 (ifc)	Xeon	1.7GHz	1	SuSE	-	-	88.3
UP264/667F	21264	667	1	SuSE	-	-	116
SS264/700F	21264	700	1	SuSE	-	-	123.7

　

　

P4L/2.0GHz 16CPU GbE/Parallel : Linpack 33.5Gflops (速報値)

　

Computer	CPU	# of CPU	Network	NSIZE	Gflops
HPC-P4L/1.7GHz ( PGI + ATLAS )	Pentium4/1.7GHz	4	GbE (mpich ch_p4)	2000	3.27
				5000	5.81
				8000	6.70
				10000	7.21
				15000	7.75
.	.	.	.	.	.
HPC-P4L/2.0GHz HPLinpack 1.0 ( PGI + ATLAS )	Pentium4/2.0GHz	16	GbEカスケード接続 (mpich ch_p4) MPICH 1.2.1	2000	4.190
				5000	12.46
				8000	18.60
				10000	21.45
				15000	26.96
				20000	29.90
				25000	31.84
				30000	33.48
.	.	.	.	.	.
HPC-P4L/2.0GHz HPLinpack 1.0 ( ifc + mkl )	Pentium4/2.0GHz	4	GbE (mpich ch_p4) MPICH 1.2.1	10000	4.737
HPC-P4L/2.0GHz HPLinpack 1.0 ( ifc + ATLAS )				10000	8.038

　

Linpackはネットワーク負荷が低く「商業PCクラスタ」出荷用検査ツールとしては不十分

SuperComputerTop500を覗くとFastEternet接続の256CPU PIIIクラスタで128〜256GflopsSくらいの性能は出ています。弊社でも出荷時検査の一部としてLinpackを用いており、1CPUあたりおおよそ2Gflops出ることを確認した後出荷しています。しかし、Linpackはネットワーク負荷が低くPCクラスタ出荷用検査ツールとしては不十分です。そのため、「姫野ベンチ」や「Gaussian98 Parallel」、「Amber6 Parallel」など動作特性が異なる計算も同時に用い、「パラレル計算機の出荷テストセット」としています。

　

PCクラスタでは「Linpackの公式」どおりの性能が出てあたりまえ

「Linpackの公式」

Pentium4なら CPU数 x 2.0 Gflops
PentiumIIIなら CPU数 x 0.5 Gflops

ここでLinpackを用いたSuperComputerTOP500についての予備知識を整理しておきます。まず、並列のLinpackは当然シリアルのLinpackと異なります。従来は並列Linpackは各自が用意しなければなりませんでした。それが大変なので現在では標準並列Linpackベンチマークとしてhplが整備されてきました。hplによりLinpackベンチマークテストは容易にできるようになりました。また、SuperComputerTOP500ではCluster500とTop500がありますが双方ともテスト方法に違いはありません。

さて以下のグラフはwww.Top500.org からPentiumIIIクラスタシステムの性能報告を抜き出したものです。これを眺めると、Linpackベンチマーク性能は（0.535×プロセッサ数）という直線回帰が可能です。すなわち、PCIIIクラスタでのLinpack性能追求は「公式どおりの性能が出てあたりまえ。」とすべき時期に到達したということです。

　

（表　TOP500 2001 June Listより）

Rank	Manufacturer	System	CPU	# of CPU	Rmax (GFlops)	Rpeak (GFlops)
86	IBM	Netfinity Cluster	PIII 933 MHz	520	285.00	485
156	Self-made	CLIC	PIII 800 MHz	528	143.30	422
予測	HIT	Open-SCC	P4 2GHz	64	132 (est)	256
予測	HIT	Open-SCC	P4 2GHz	32	66 (est)	128
参考	HIT	Open-SCC	P4 2GHz	16	33.48	64

上表での回帰直線との乖離が大きいデータはTOP500 2001 June Listで156位のセルフメイドマシンです。直上のシステムはさすがIBMの組んだシステムでRmaxで倍の性能を出しています。さらに、Cluster500では1Gflops/CPUが標準になりつつあります。また、現在発展途上のPentium4、XeonクラスタシステムではKernelやコンパイラの選定をうまく行い単体性能を最高に引き出すような基礎的な事柄から新たなノウハウの蓄積を開始しなければなりません。

　

国内では商用クラスタ機ビルダーでさえも苦しむLinpack

弊社のように常時クラスタ機を量産している会社においてはLinpackは日常のテストツールの内でももっとも基礎的なものですから、これを難しいなどと感じることはありません。このように成熟の極みにあるPentiumIIIクラスタではあっても、システムチューニング技術の有無がトータル性能を大きく左右しています。ですから、量産経験に乏しい国内の商業クラスタ機ビルダーにとっては未だに大きな壁になっているようです。しかし、納入・検収の時点でLinpack性能すら出せないようなシステムが「商業PCクラスタ」と称することはお客様を混乱に導くことにもなり、節度が求められます。また、お客様としても事前にベンチマークテストを求める必要があります。

　

「セルフメイドPCクラスタ」がLinpackを目標にされるのは一理ある

一般の商業クラスタ機ビルダーでさえも、いまだにLinpack程度で苦しんでいるのですから、スクラッチから「セルフメイドPCクラスタ」を構築される場合には、やはりLinpackは大きな通過点です。Linpackで性能が出せてるということは、CPU、コンパイラ、OS、ネックワークがクラスタ機として機能を果しているということの確認にはなります。実はここまで到達しているシステムでなら、HPCに向けたシステムチューニングを順調に行い安定した性能を追求することに光が見えてきます。

　

　

ifc + ATLASのMatM(行列積テスト)で3.8Gflops記録 <速報 9/20>

Open-SCC内のPentium4/2.0GHz機でMatM行列積テストをifc +ATLAS環境で実行したところ、400x400で最大値3,835.20Mflopsを記録しました。いよいよPentium4やXeonが真のスパコン性能を顕在化させられるようになってきました。テストに利用した MatM公開コード はソースコードを公開しています、システム測定用にご利用ください。

BLAS版 MatM

1 ifc + mkl (Intel Math Kernel Library)
2 ifc + ATLAS

BLAS版 MatM P4/2.0GHz <速報 9/20>

　

　

Intel Fortran Compile (ifc) は９月中旬より発売開始

　

Intelのコンパイラ製品サイトへリンク http://developer.intel.com/software/products/

ifcは９月11日に発売になりました。当初はUSのIntelオンラインストアでネットワーク経由での購入になります。ダウンロード版の価格は商用ライセンスが399ドル、アカデミックライセンスは100ドルと発表されました。また一ヶ月のテスト版 (サポートあり) と、非商用版 (サポートなし) の無償ライセンスが用意されています。この「非商用 (Noncommercial)」が該当する範囲はかなり広いと解釈できます。該当しないと明示されているのは「商用ソフトの開発と商用利用」ですから、弊社のお客様の大部分が「非商用」に該当し、無償ライセンスを利用することが可能であると思います。

弊社からクラスタ機をご購入される場合は、システムをセットアップする段階でコンパイラが必要になります。この手続きの工夫を考えています。

ifc発売当初はCDメディアと英文印刷ドキュメントが付属します。暫くしてから、日本語版のドキュメントが完成し添付される模様です。この日本語版ドキュメントはネットワーク上にも公開されると予想されますから英語版やダウンロード版を入手された方でも後には日本語ドキュメントを入手することができる筈です。

ifcがほぼフリーソフトに近いライセンス管理で流通する背景として、新しいCPUの性能を上手に引き出せる良質のコンパイラに比較的自由な流通パスを与え、NetBurstアーキテクチャの潜在性能を一刻も早く顕在化させることで、競合他社との差別化を加速しようとするIntel社の計略があります。しかしこの計略はユーザにとっても有益であるので善い作戦です。

Intel Fortran Compiler価格表

項目	定価	現金特価
Intel Fortran Compiler for Linux	-	-
Intel Fortran Compiler for Linux (Academic)	-	-
Intel C++ Compiler for Linux	-	-
Intel C++ Compiler for Linux (Academic)	-	-

　

　

　

　

[状況の整理と予測]

計算機の主流がRISC-WSからIA-Linuxへ大きく移る

高速なPentium4やXeonから始まり、来年後半から投入される IA64 (McKinley) に続くIA-Linux Parallel環境が今後のHPCの主流に育ってゆくと考えると、これまで利用してきたUNIX開発環境からLinux開発環境へ最小のロスで移行しうるパスの発見が重要です。

IntelがLinux Fortran開発環境整備に積極的

従来Intel社のFortranはWindowsNT用しか発売されておらず、DEC Fortran for WindowsNTユーザが多い日本では無名の存在でした。しかし、新しいLinux + Pentium4環境ではまだ業界標準は未確立のため、Intel Fortranが業界標準になりうる可能性が極めて高いです。

「コンパイラを制する者が計算機を制する。」とするなら、ここに着眼したIntelは慧眼です。2001年5月よりIntel Compiler for Linuxのフィールドテストが開始されました。弊社でもテストを行っており良い性能が確認できています。このコンパイラはPentium4に対する最適化機能を持つとともに、IA64アーキテクチャにも対応する最適化機能を持っています。

さらにIntelは以下の投資を行っており、着々と技術蓄積を遂行しているように思えます。

１．2000年夏、Intel社はKAI社を買収。KAI社はKAPという製品名のソースコード最適化ツールで高い技術力を示している会社です。
２．2001年夏、Intel社はCompaq社のコンパイラ開発チームを買収。旧DEC社からのコンパイラ技術がCompaq社を経てIntel社へ流れた。

これらの状況を俯瞰すると、望むと望まざるにかかわらず選択肢はIntel Compiler for Linuxに絞られてしまうようです。ことの良し悪しは置くとして、このように判断を下すならば開発環境を一刻も早くIntel Compiler for Linuxに移行するほうが得策です。

　

ifc の恐るべき機能 <1GBの壁越え>

ifcを使えばFortranプログラムを修正することなく、1GB以上のメモリサイズを必要とする計算に対応したバイナリが自動生成される。

ifcには恐るべき機能が内蔵されています。これまでIA32マシンに2GBのメモリを搭載していてもPGI Fortranで普通に利用できるメモリ空間は1GB(実際には約900MB)でした。PGI Fortranでこの制限を越えるには「割付配列」を用いたプログラムに改編するというかなり面倒な作業が必要でした。そのため、「せっかく2GBものメモリが搭載可能なマシンなのに非常に惜しい。」との声がお客様からあがっていました。

Intel社が開発中のIntel Fortran Compiler for IA Linuxにはこの改編作業を自動的に行う機能が備わっていることが確認できました。ifcを使えばプログラムに何の修正を加えることなく900MB越えのメモリ利用域を利用できます。ただし、PGI Fortanで割り付け配列を使ったときよりは多少パーフォーマンスが落ちます。しかし、プログラム書き換えの苦労を考えれば、何も考えなくてもメモリをフルに使えるメリットは計り知れません。さらに未検証ですがHPC-IAX (Xeon CPU) 機を用いれば3GB程度まではメモリを利用が期待できます。これで、64ビットアーキテクチャとの差異がまた一つなくなりました。

　

姫野ベンチLargeで「ifc自動改編ビルト版」と「PGI割付け配列版」の性能比較

性能ではifcビルトは多少劣りますが、変更の手間なしでメモリをフルに利用できる恩恵は非常に大きいです。

メーカー	機種	CPU/CLK	結果実測速度 (MFLOPS)
NEC	SX-5	8GFLOPS 250MHz	5,366
FUJITSU	VPP5000	9.6GFLOPS 300MHz	5,013
HITACHI	SR8000/E	9.6GFLOPS -	4,470
FUJITSU	VPP800	8GFLOPS 250MHz	3,779
HITACHI	SR8000	8GFLOPS -	3,684
HIT	P4L	Pentium4 1.7GHz (PGI割付け配列版)	495
HIT	P4L	Pentium4 1.8GHz (ifc自動改編ビルト)	440
HIT	P4L	Pentium4 1.7GHz (C言語版)	341
HIT	UP264L/750E	750MHz	240

　

　

ifc のFortranとしての完成度は実用域 <速報>

ifcのFortran Compilerとしての完成度、すなわちエラーを含んだソースコードをコンパイル、実行したときにどのような挙動を示すかを http://www.polyhedron.com/compare/linux/diagnose.html に掲載されているFortranコンパイラの可用性テストでチェックしています。テストに用いているifcはベータ版ですが問題のない動作をしています。つまり、間違いは間違いと指示してきます。また文法チェックや配列境界のチェックなどをどこまでやるかなどを、コンパイルオプションあるいは関数の呼び出しで設定できるようになっています。このテストで判断すると、実用域に到達していると思って良いようです。製品版がリリースされ次第、再度テストし結果を報告いたします。 またCompaq Fortranを基準として完成度の検討もレポートしたいと考えています。

　

　

ifc はPGIより高性能を出す傾向にある <速報>

ifcの性能評価をASCI LIVERMORE FORTRAN KERNELS http://www.llnl.gov/asci_benchmarks/asci/limited/lfk/ にて行っています。その結果、かなりの性能が出ていることがわかってきました。しかし、現在ご報告している結果はifcβで得られた結果ですので、製品版のifcを入手次第、 性能テストを行う予定です。

LIVERMORE FORTRAN KERNELS 実行結果 <速報値>

.	ifc	pgif90-sse	pgif90-prefetch
LFK最大値	2,244	1,623	961
LFK幾何平均	419	235	240

単位 : MFLOPS
(テストマシンはOpen-SCC内のPentium4 1.8GHz機を使用。ifcはβ版でテスト。)

　

　

Linpack ifc mkl (Intel Math Kernel Library) vs ATLAS (速報)

ifc上で選択できる代表的な数値演算ライブラリであるATLASとmkl (Intel Math Kernel Library)の性能比較を行いました。テストに用いたベンチマークはLinpacです。その結果、ATLASが良い成績でした。参考にPGI + ATLASの結果も掲載しておきます。

Computer	CPU	# of CPU	Network	NSIZE	Gflops
HPC-P4L/1.7GHz ( PGI + ATLAS )	Pentium4/1.7GHz	4	GbE (mpich ch_p4)	2000	3.27
				5000	5.81
				8000	6.70
				10000	7.21
				15000	7.75
.	.	.	.	.	.
HPC-P4L/2.0GHz HPLinpack 1.0 ( ifc + mkl )	Pentium4/2.0GHz	4	GbE (mpich ch_p4) MPICH 1.2.1	10000	4.737
HPC-P4L/2.0GHz HPLinpack 1.0 ( ifc + ATLAS )				10000	8.038

　

　

姫野ベンチではPGIが良い成績を出している <速報>

Open-SCC内のXeonでifcとPGIを用いて姫野ベンチのサイズを変えながら実行したところPGIが良い成績を記録していました。(9/17)

　

　

MatM行列積テスト <速報>

MatM公開コード ソースコードを公開しています。

　

MatM を使用した下記のシステムの比較比較

BLAS版 MatM

1 ifc + mkl (Intel Math Kernel Library)
2 pgf90 + PGI BLAS
3 pgf90 + ATLAS
4 ifc + ATLAS

　

BLAS版 MatM P4/2.0GHz <速報 9/20>

　

BLAS版 MatM Xeon/1.7GHz <速報 9/17>

　

non BLAS版 MatM

1 ifc
2 pgf90

マシンは、OpenSCC内のiax01(Xeon 1.7GHz)を使用。

non BLAS版 Xeon/1.7GHz <速報 9/17>

　

　

[余談]

これまでは面倒なFORTRANの割付け配列への改編が必要でした

普通のFORTRANプログラムでは配列の確保にcommon文が使われています。common配列では動的メモリ割り当て (FORTRANの用語では「割付け配列」)が使えません。しかし、現状のIA32-Linux環境では、動的メモリ割り当てを使わないと1GB超のメモリを使えません。また、FORTRANのプログラムではcommonを多用するのが伝統的になっています。したがって、FORTRANプログラムを 1GBを超えて動作させるためにはcよりも苦労しなければなりません。

姫野ベンチ程度の短いプログラムの場合、commonから「割付け配列」への書き直し

1.smallを使って、commonを割付け配列に変更する
2.正しく動作するか確認する
3.common配列と割付け配列のパーフォーマンスの差もチェックする
4.largeにサイズを変更して、動作を確認する

実用的なプログラムの場合commonを多用していると考えられます。1GBを超えて動作させるためには書き換えの量も大きくなるでしょう。これを短時間で間違いなく「割付け配列」用に書き換えるのは「結構面倒なのではないだろうか?」というのが正直な感想です。しかし、スキルはそれほど高くない機械的な作業なのでFORTRANがある程度わかれば、時間さえかければできる作業ではあります。

　

[姫野ベンチLarge解説]

キャッシュが役立たないベクトル機の独擅場領域、姫野ベンチLarge(512x256x256)

「姫野ベンチLarge」は512x256x256のメッシュを計算するため約1.8GBもの配列データをメモリ上に確保しています。さらに、演算コ アでは10MB以上のデータを最内側ループで転送する計算を行っており、小型計算機には不利なベンチマークテストであり、ベクトル機の独壇場とみなされいました。事実、8MBのキャッシュメ モリを搭載した弊社のUP264L/750Eであってもキャッシュミスが気になっていました。そのため姫野ベンチのサイト (姫野ベンチマーク98・実測結果メーカー順リストへリンク : http://w3cic.riken.go.jp/HPC/HimenoBMT/himenoDB1.html ) での Largeサイズ( 512x256x256 ) に関しては各社スパコンのみが覇を競っており、唯一弊社のUP264L/750Eを除いて、他のアーキテクチャの結果報告は掲載されていませんでした。

しかしこれまで、IA32 Linux PGI Fortran環境で姫野ベンチLargeをコンパイルするためには「面倒なFortran割り付け配列への改編作業」が必要でした。ところがifcを用いることで、何の改編作業もなくコンパイルした「姫野ベンチLarge( 512x256x256)」をHPC-P4/1.8GHz 2GBメモリ搭載機で実行することができました。そして440MFlopsと満足できる性能が得られました。

440MFlops以上の性能は驚くべき記録です。これは、10MB以上のデータを最内側ループで転送するキャッシュメモリが無効な領域の計算で1.76GB/sの持続的なCPUメモリ間のデータ転送速度を記録したことでもあります。Pentium4のDirectRDRAM (PC800メモリ : 理論性能3.2GB/sec) の性能があって始めて記録できる値ということです。(MFLOPSとMB/secは単純に考えるとMB/sec=4*MFLOPSと換算できるので、440MFLOPSを４倍すると1.76GB/secとなります。) 弊社ホームページには「Pentium4はスパコンである。」との記述が頻出していますが、この結果はそれを裏打ちしています。

　

[1GB越え問題に関するお客様との対話]

<<お客様のご質問>>

貴社のOpenSCCにて数値計算プログラムを試しています。小規模計算の場合にはプログラムは問題なく動作するのですが、大規模計算ではメモリ容量が最大の[se1]でもメモリサイズ制限の問題からうまく動作していません。

<<HITからの回答>>

IA32では1GB以上のメモリを使う際には64bitプラットフォームと異なり工夫が必要です。一般的にはプログラムの書き換えが生じます。しかし Intel Fortran Compiler(ifc) を使用すると特別なオプションを指定する必要もなく、1GB以上のメモリを使用することが確認できました。まだ私どもの検証もあまり進んでいないのですが、よろしければ試していただけないでしょうか。弊社では、姫野ベンチ等いくつかのプログラムについて1GB以上のメモリを使用したプログラムの動作を確認しています。OpenSCC内の[se1]にログインしていただければ使用できます。ifcというコマンドを使用してください。コンパイラは、現行はベータ版です。近日中に製品版が発表されるようです。また、よろしければ結果を教えていただけると幸いです。

<<お客様のご感想>>

早速OpenSCCにてIntel Compilerでビルドしたプログラムを走らせみましたところ問題なく動作しました。コンパイルオプションは何も付けておりませんが、それでもかなり速いようです。以前使用していたVPP5000と比較してもそれほど劣らない気がいたします。

さらに、小さい系でも試してみましたところ、PGI Compilerと比較して２割近く速いようです。

<<HITからのお礼>>

さっそくのテスト結果ご報告ありがとうございました。多くの方にとって朗報であると思います。これを機に弊社OpenSCCでもifcを利用可能といたしました。引き続きテストをお待ちしています。

Intel、インテル、Intel ロゴ、Intel Inside、Intel Inside ロゴ、Pentium、Xeon、Itanium は、アメリカ合衆国およびその他の国におけるIntel Corporation またはその子会社の商標または登録商標です。その他の社名、商品名などは、一般に各社の商標または登録商標です。機器の仕様は予告なく変更される場合があります。
©Copyright 1997-2006 HIT Co., Ltd. All rights reserved.