Comments
Description
Transcript
計算環境に依存しない行列計算ライブラリインタフェース
計算環境に依存しない行列計算ライブラリインタフェース SILC 長 谷 川 秀 彦†1,†3 須 梶 山 民 人†3 中 小 武 守 恒†3 藤 田 島 井 礼 研 昭 仁†2,†3 額 吾†4,†3 高 宏†6,†3 西 田 橋 田 彰†3 大 介†5,†3 晃†2,†3 本報告では、行列計算ライブラリの使い勝手を向上させるため、(1) データの受け渡しと演算処理 の指定を分離する、(2) 演算処理の指定は文字列（数式）で行う、(3) 演算処理にはユーザプログラム のメモリ空間を使用しないという特徴を持つライブラリインタフェース SILC (Simple Interface for Library Collections) を提案する。開発中の SILC の行列計算向き命令記述、多様な計算環境（逐 次、並列）での実装方式についても述べる。SILC を利用することで、ユーザはデータは必要最低限 （作業領域はいらない）、計算環境が変わってもソースプログラムは変更不要、複数ライブラリの同時 使用が可能（ライブラリの出所によらない) というメリットを享受できる。 Computing Environment Independent Interface for Matrix Computation Library Hidehiko Hasegawa,†1,†3 Reiji Suda,†2,†3 Akira Nukada,†3 Tamito Kajiyama,†3 Kengo Nakajima,†4,†3 Daisuke Takahashi,†5,†3 Hisashi Kotakemori,†3 Akihiro Fujii†6,†3 and Akira Nishida†2,†3 We propose a new library interface SILC (Simple Interface for Library Collections) which (1) separates passing data and requesting computation at calling library program, (2) uses mathematical expression in text data for a computation request, and (3) uses no user program’s memory for computation done by library programs. Then the SILC enables users to prepare no working storage in a user program for any library program, to run a user program in any computing environment with no program change, and to use many types of libraries in a same program easily. This advantage is practically important for users to use their program in seamless. 1. は じ め に 数値シミュレーションの核となる行列計算（連立一 次方程式の解法、固有値計算、 FFT など）には、様々 な高性能数値計算ライブラリが提供されている。1) 実 際は、それらがユーザの書こうとしているプログラム から手軽に使えるわけではない。ライブラリを使うに は、ライブラリが定めた形式のデータを用意し、必要 †1 筑波大学 図書館情報メディア研究科 Grad. Sch. of Lib., Info. & Media Stud., U. of Tsukuba †2 東京大学 情報理工学系研究科 Grad. Sch. of Info. Sci. & Tech., the Univ. of Tokyo †3 科学技術振興機構 戦略的創造研究推進事業 JST CREST †4 東京大学 理学系研究科 Grad. Sch. of Science, the University of Tokyo †5 筑波大学 システム情報工学研究科 Grad. Sch. of Sys. & Info. Eng., University of Tsukuba †6 工学院大学 Kogakuin University な作業用領域（多くは配列）を見積もって確保して、 それらを決められた順序でサブルーチンに渡してや らなければならない。ソースプログラムで提供された ライブラリの場合は、あらかじめ使用するコンピュー タでコンパイルしておく必要がある。うまくリンクが できて、プログラムが実行できたとしても、原因不明 の実行時エラー（アルゴリズムに依存する不可避なエ ラーやシステムに関係したエラーなど）によって、新 たに頭をかかえることになるかもしれない。うまく実 行できたとしても、他の計算環境（たとえばパソコン から PC クラスタ）に移ろうとすれば、プログラムの 書き換えに再び労力を費やすことになる。 本報告では、(1) データは必要最低限（作業領域は いらない）、(2) 計算環境が変わってもソースプログ ラムは変更不要、(3) 複数ライブラリの同時使用が可 能（ライブラリの出所によらない) という特徴を持つ ライブラリへのインタフェースとそれを実現するシス テムについて述べる。 ライブラリ本体や性能に関しては現状と比べて大き な変化はないが、個々のライブラリプログラムはその ままでも、複数のライブラリから必要なライブラリプ ログラムが同時使用できれば、ユーザの選択肢は格段 に広がる。また、逐次、共有並列、分散並列といった 計算環境に依存しないインタフェースを提供すること で、ユーザが作成したプログラムの稼働範囲を広げる こともできる。重要なのは、ライブラリの利用者とラ イブラリプログラム作成者にとっての単純さである。 2. 数値計算ライブラリの問題点 ライブラリプログラムは共通に使われるプログラム の集まりで、ユーザはこのプログラムを利用すること によって、内部の詳細を知ることなく目的の処理が実 行できる。2) C や Fortran プログラムから使われる 数値計算のライブラリが数値計算ライブラリである。 たとえば Fortran で連立一次方程式 Ax = b の解を 求めるプログラムは次のようになる。ここでは、ライ ブラリプログラム LU で係数行列 A を LU 分解し、 SOLVE で右辺ベクトル b に対する前進後退代入を 行う。 PARAMETER (LDA=101,N=100) REAL *8 A(LDA,N), B(N) INTEGER IP(N), STATUS 係数行列を配列Ａに、右辺を配列Ｂに与える CALL LU(LDA,N,A,IP,STATUS) IF( STATUS.EQ.0 ) THEN CALL SOLVE(LDA,N,A,IP,B) /* A の値は壊され、解が B に入る */ END IF END LU と SOLVE には、ライブラリの仕様に定められ た形式のデータを用意し、所定の順序で変数を記述し なければならない。同じ連立一次方程式を別のライブ ラリプログラムで解く場合は、データの格納方法、変 数の並べ方などに変更がいる。どのプログラミング言 語から使えるのかについても注意がいる。一般には、 プログラムを書き換えず、同一のユーザプログラムで 単精度計算と倍精度計算、４倍精度計算の結果を比較 することは不可能である。 疎行列に対する反復解法のライブラリでは、計算ア ルゴリズムは同じでも、用いられるデータ格納形式が 多数あるため、それらに対応したプログラムを用意し ていてはライブラリプログラムの数が膨大になってし まう。そこで、プリミティブな計算である行列・ベクト ル積などのインタフェースの仕様を定めておき、この 部分の計算プログラムをユーザに作成させる ( Reverse Communication3) )。このようなやり方では、完成度 の高いライブラリをユーザに提供できたことにはなら ない。 このような問題を解消するため、Common Component Architecture4) ではオブジェクト指向言語によ るラッパーを用意し、多くのライブラリをスムースに つなげて各種プログラミング言語から利用できるよう にしている。プログラム間で CCA の規約に沿った データ受け渡しを行うためのラッパーは誰かが用意す る必要がある。このような枠組みは、多くのデータ形 式に対応できるが、新たなデータ形式を導入するのは たいへんな作業になる。 SPMD 形式の並列プログラムからライブラリを使う ことを考えよう。ユーザプログラムのそれぞれが逐次 ライブラリを呼び出したり、持っているデータ全体を 渡して並列ライブラリを呼び出したりするのは既存の 呼び出し法でもできる。しかし、 p 並列の並列プログ ラム全体が、 q 並列で構成された並列ライブラリを呼 び出す場合は、ライブラリへのデータの渡し方、デー タ全体の情報の交換など、ユーザプログラムとライブ ラリプログラム間のインタフェースに難問が発生する。 ライブラリプログラムがすべての場合の準備しておく のは不可能だし、並列計算プログラムとライブラリプ ログラム間のインタフェースに決定版はない。このた めユーザプログラムと並列計算ライブラリ間のデータ 受け渡しは、並列行列計算ライブラリ ScaLAPACK5) のようにファイルを利用するのが一般的である。 これらの問題の原因は、 • 格納形式や処理の詳細を制御する引数など、低レ ベルの記述を用いていること • 名前やインタフェースが、ライブラリ、精度、格納 形式、並列処理手法などの実装ごとに異なること である。このようなライブラリ呼び出し法は手軽かつ 直感的で、逐次プログラム同士の場合、少数の限られ たライブラリを使う場合、他のプログラムと独立な場 合などにはよいが、並列プログラムの場合、多くのプ ログラムを合せて使う場合、複数の計算環境で実行す る場合などでは問題となる。 3. SILC (Simple Interface for Library Collections) の考え方 ユーザとしては、多様な計算環境を意識せず、特に 逐次か並列かを意識せず、同一のプログラムが変更な しに使えればうれしい。そこで、単純にデータを渡し て、計算の一切を任せることを考える。具体的には、 仮想的な計算環境にデータを預けて、預けたデータに 対する演算処理を依頼し、必要になったときに仮想的 な計算環境から結果を受け取るような仕組みである。 ユーザは、仮想的な計算環境が逐次か並列か、どんな ライブラリが動作しているかなどは意識しなくてよい し、作業に必要な領域を用意する必要もない。 われわれは上記の「夢」を実現するため、三つの特徴 ( 1 ) データの受け渡しと演算処理の指定を分離する ( 2 ) 演算処理の指定は文字列（数式）で行う ( 3 ) 演算処理にはユーザプログラムのメモリ空間を 使用しない を持つインタフェース SILC (Simple Interface for Library Collections) を提案する。演算処理の指定に文 字列を使うのは、複数のプログラミング言語に対して 統一的なインタフェースを提供するためである。 SILC では、２章で示した連立一次方程式 Ax = b の解法を PARAMETER (LDA=101,N=100) REAL *8 A(LDA,N), B(N), SOL(N) INTEGER IP(N), STATUS 係数行列を配列Ａに、右辺を配列Ｂに与える CALL PUT(’A’, LDA, N, A, STATUS) CALL PUT(’b’, N, B, STATUS) /* A, B を転送し A, b と名付ける */ CALL SILC(’ x = A\b ’) /* 連立一次方程式を解く */ CALL GET(’x’, N, SOL, STATUS) /* 解 x を配列 SOL に転送する */ END のように書く。必要に応じて、どのライブラリプログ ラムを使うとか、演算精度はどうするかなどを指定 する。 SILC システムでは、ライブラリプログラムとユー ザプログラムが共通に利用する仮想的なメモリ空間 を用意し、データはそこに存在させる。ユーザプログ ラムは計算に先立って、必要なデータ（行列、ベクト ル）に名前をつけてその仮想的なメモリ空間におき、 それから処理を依頼する。指示に応じて、ライブラリ プログラムが仮想的なメモリ空間からデータを受け 取って処理し、処理結果をその空間に戻す。処理結果 は必要になったときに受けだす。仮想的なメモリ空間 内のデータは、演算によって破壊されることなく、消 滅を指示されるか仮想的なメモリ空間が消滅するまで 存在する。ユーザプログラムとライブラリプログラム は仮想的なメモリ空間とデータのやりとりができれば よく、それぞれの動作環境（逐次か並列かなど）は異 なってもよいし、プログラミング言語の制約もない。 データ形式の変換は SILC システムの担当で、ユーザ プログラムのデータ構造に対応した PUT, GET ルー チン、既存のデータ形式との変換は、データ形式の数 だけ必要になるが、それでも個々のデータ形式に対応 した解法ルーチンを作るよりは少ない労力ですむだろ う。’X=A+B; Y=A-B’ のような演算指示から自動的 に並列性を抽出すれば、逐次実行のプログラミング言 語中に並列処理を記述したことになる。並列実行可能 なリソースがあれば並列実行によって高速化できる。 SILC の考え方は、プログラミング言語、使用するラ イブラリ、計算環境（単一マシン、複数マシン、並列 環境、Grid 環境）に左右されない一般的な枠組みを 提供することにある。SILC の仕組みを使えば、パソ コン上のスクリプト言語 Python からクラスタで動作 する ScaLAPACK を利用するようなシステム6) も容 易に構築できる。 上記のような便利さを実現するために引き換えにし た部分もある。たとえば、 • 必要なメモリ量が増えること • データ転送が必要になること • メモリコピーが増えること • すべてが動的であること である。しかし、メモリ量の制約は緩和される方向だ し、将来的にはデータ転送も高速化されるだろう。 さらに、行列計算は大量のデータを必要とし、それ 以上に膨大な演算が必要なために高速化が強く要求 されていることと、どんな大規模行列であっても演算 指示を数式で書けば高々数文字で書けるという特徴が ある。たとえば、N × N の密行列 A の行列式の値 det(A) を求めるには、N 2 のデータを転送し、 O(N 3 ) の演算を行うが、結果は一つのスカラー量である。す なわち、いったんデータを仮想的なメモリ空間に転送 してしまえば、数十バイトの文字列で膨大な演算量の 処理を制御することができる。しかも、演算を実行す るのはその計算環境に最適化された並列プログラムで ありうる。したがって、現状でも転送に必要なコスト を上回る性能向上の可能性があるだろう。 ライブラリにあるプログラムをリンクしてユーザプ ログラムに取り込むという静的な考え方と、計算を依 頼した時点で最新のライブラリプログラムによって処 理されるという動的な考え方には、大きなギャップが ある。ライブラリとバージョンを指定して使えるよう にすることも可能だろうだが、現時点では多様なライ ブラリの最新版を容易に使えるようにするのが目的で ある。したがって、古いバージョンのライブラリプロ グラムは将来に残らず（存在せず）、これまでの「あ る時点でライブラリをリンクして凍結したユーザプロ グラム」とは発想を転換してもらう必要がある。 以上の議論から、 SILC のメリットをまとめると以 下のようになる。 3.1 ユーザのメリット ( 1 ) 計算環境（単一マシン、複数マシン、並列環境、 Grid 環境）によってソースコードが変わらな い。通信時間、演算時間は変わってもプログラ ムの全体像は変わらない ( 2 ) 仮想的なメモリ空間を経由して複数のプログラ ムを容易に組み合わせられる。また、仮想的な メモリ空間をデータ変換に用いたり、プログラ ムの分割に用いることもできる 同一インタフェースで複数のライブラリプログ ラムが利用できる。データが仮想的なメモリ空 間に登録できれば、あとはどの「ライブラリの 機能」が使いたいかを記述すればよい ( 4 ) 並列実行が自然に導入される。ユーザプログラ ムとライブラリプログラムは非同期並列実行で あり、リソースが許せば高速化される。演算処 理の指定から並列性が自動抽出されて並列実行 される可能性もある 3.2 ライブラリ開発者のメリット ( 1 ) プログラムを最新に保てる。バグ入りのプログ ラムをリンクして残されることもなく、常に最 新のプログラムを使ってもらえる ( 2 ) ユーザプログラムのデータ構造を意識しなく てよい。仮想的なメモリ空間のデータ形式は自 由なので、最適なデータ形式、精度、分散方法 などを選択できるし、１種類だけのデータ格納 方式に対応した解法でも（性能を意識しなけれ ば）多様なデータ格納形式に対応できる可能性 がある ( 3 ) 作業領域の確保や分散方法の変更が、ユーザプ ログラムとは独立に行える。インタフェースを 変更することなく、実行環境に合わせた最適化 ができる ( 4 ) 既存のアプローチと矛盾しない。既存の大多数 のプログラムを SILC の枠組みに組み込める (3) 4. SILC の仕様と実装方式 4.1 SILC の命令記述 SILC の命令記述言語は一種のプログラミング言語 である。しかし SILC が線形代数を中心とする数値計 算ライブラリに用いられることを目的としていること から、数学的な演算を簡易に記述できるように高度化 された言語とする。しかし、ユーザが習得しやすいよ うに、既存のプログラミング言語や数学システムとあ まり異ならないように注意も払う。 識別子： SILC では数値や行列などに名前を付け てプログラミング言語の「変数」のように扱うことが できる。しかし、型やサイズの宣言のようなことは行 わない。識別子には任意の型、任意のサイズのデータ をバインドすることができる。単純な代入文では、識 別子にすでにどのような型のどのような値がバインド されていても無視され、新しい値がバインドされる。 制御構文： SILC では反復を記述する構文を意図 的に排除している。SILC は他のプログラミング言語 からライブラリとして呼び出されるため、反復が必要 であれば呼び出し側のプログラミング言語の反復構 文を用いれば十分である。もしそのような使い方が著 しく非効率なのであれば、実行時に命令が供給される SILC の構文で反復を記述してもやはり非効率であろ うから、そのような操作はライブラリレベルで実現す るべきである。また、現在予定している言語では、条 件分岐構文もない。従って、SILC の命令は本質的に すべてが単純な実行文である。しかし、条件分岐の一 種であるマスク演算 (Fortran 90 以降にある where 文のようなもの) は今後追加を検討する価値があると 考えている。 エラーの防止および意味の明確化： SILC では、 行列やベクトルなどの要素・範囲アクセスの際には添 え字範囲のチェックを行う。また、記述された命令の 意味が曖昧にならないように文法が設計されており、 実行時のチェックを行うことができる。まず、代入は 「文」として扱い、C のように一つの文に複数の代入が 行えるようにはしない。もし代入を式として扱うと、 A = f(X) + (X = Y) のような命令では f の引数として渡されるのが X の 代入前の値なのか、代入後の値なのか明確でなくなっ てしまう。同様の理由で、（値を返す）関数の引数は 値を変更するものを許さない。例えば A = f(X) + g(X) のような命令で、f と g が引数を変更してしまうよう であれば、渡される引数の値が不明確になるからであ る。そこで、引数を変更できるのは値を返さない「手 続き」に限ることとする。さらに、一つの手続きに値 を変更できる引数が複数ある場合、引数として渡され るものに重複がある「エイリアス」が生じないよう実 行時にチェックを行う。例えば p という手続きの最初 の 2 つの引数は値が変更され得、最後の引数はそう でない場合、 p(X[0:9], X[10:19], X[0:19]) のように呼び出せば可である（最後の引数はコピーが 作られて渡される）が、 p(X[0:9], X[5:14], Y) では最初の 2 つの引数が干渉してエイリアスとなって おり、実行時エラーとなる。しかしエイリアスチェッ クに時間がかかり性能に影響するような場合には、エ イリアスのチェックを行わないオプションの導入も検 討する必要があると思われる。 演算子など： 詳細は紙数の都合で記述できないが、 概略としては以下のようになる。 単項演算子：配列参照 A[1:2], 関数呼び出し f(x), 共役転置 A’, 複素共役 A~, 複素行列に対する単純転 置 A’~ または A~’。なお、配列の参照では添え字と して整数ベクトルを与えることができ、順序置換や gather/scatter などの演算が記述できる。 二項演算子：四則演算、剰余 a % b, 連立一次方程 式の求解 A \ b (Ax = b の解 x を求める) その他、ベクトル・行列を生成する構文などが予定 されている。また、各種の定数・関数・手続きも必要 に応じて実装される予定である。 クライアントプロセス ユーザプログラム SILC クライアント ルーチン インタフェース スレッド リクエストキュー 実行スレッド 図2 クライアント・サーバが同数の並列プロセスからなる構成 サーバプロセス 図1 クライアント１プロセス、サーバ１プロセスの構成 ライブラリ呼び出し： ユーザプログラムから呼ばれ る SILC ルーチン（クライアントルーチン）と、SILC サーバにおけるライブラリの実行とは、基本的に非同 期である。すなわち、クライアントルーチンがサーバ に命令を送信すると、サーバは構文チェックのみを行っ てクライアントに ack を返し、（データの読み出し命 令など必要な場合を除いて）クライアントルーチンは ユーザプログラムに制御を戻す。従って、SILC サー バがライブラリを実行している間にユーザプログラム は別の処理を行うことが可能である。 ユーザプログラムが並列の場合も、演算実行命令は 一つのユーザプロセスが依頼すれば十分である。複数 のユーザプロセスから命令が送られる場合の実行順序 制御のための SILC 命令がいくつか提供される予定で あるが、詳細は現在検討中である。 4.2 SILC の実装 クライアント・サーバ構成： 図 1 は最も簡単な構 成である、クライアント 1 プロセス・サーバ 1 プロセ スの場合の実装方式の概念図である。クライアントと サーバが同一のプロセッサ上にあってもよいし、ネッ トワークなどで結合された異なるプロセッサ上にあっ てもよい。 ユーザプログラムは SILC のクライアントルーチン を呼び出し、クライアントルーチンは基本的に引数を そのまま SILC サーバに転送する。 SILC サーバは大きく分けるとインタフェーススレッ ド、実行スレッドと、その間をつなぐリクエストキュー からなる。クライアントルーチンからの命令はインタ フェーススレッドが受信し、構文チェックが行われて リクエストキューに追加された後、ack が返される。 実行スレッドはリクエストキューから順次命令を取り 出し、命令に対応するライブラリを実行する。 クライアントとサーバが共に並列で同数のプロセス からなる場合には、クライアントごとに異なるサーバ が接続する図 2 の構成が自然である。各プロセッサに クライアントとサーバが一つづつ乗ることにより、従 来型の並列ライブラリと同じ構図となる。この場合も クライアントルーチンは命令をサーバのインタフェー 図3 並列サーバに逐次クライアントが接続する場合の構成 ススレッドに単純に転送し、サーバのインタフェース スレッドはそれをリクエストキューに追加する。各サー バのリクエストキューに格納された命令列の実行順序 の制御、ライブラリ演算で必要となるサーバプロセス 間のデータ通信などは、すべて実行スレッドが行う。 クライアントが逐次でサーバが並列の場合、図 3 実 線のようにクライアントがサーバプロセスの一つだけ に接続する方式が考えられる。この場合、実行ルーチ ンが必要に応じて命令やデータを他のサーバプロセッ サに転送し、並列実行を行う。一方、図 3 破線で示 すように単一のクライアントが複数のサーバプロセス に接続する方式も可能である。こうすることにより、 データ転送などの処理の一部が効率化できる可能性が ある。 複数のクライアントから単一のサーバに接続する図 4 のような構成も考えている。この構成は単純にクラ イアントが並列プログラムである場合も含むが、演算 結果を別プロセスで可視化したり、連成問題を複数の プログラムの疎結合で解いたりするような場合にも適 用できる。この場合にはインタフェーススレッドが複 数立ち上がり、それぞれのクライアントとのやり取り を制御する。リクエストキューは各クライアントに対 して作られ、複数のクライアントからの命令の実行順 序制御は実行スレッドが行う。 実行スレッド構成： 図 5 は現在想定しているサー バ内の実行スレッドの構成方式を示している。 まず、リクエストキューには構文解析が完了した命 令が蓄えられている。リクエストキューが複数ある場 合、 「実行順序制御」ユニットはそこから次に実行すべ 5. お わ り に 図 4 複数クライアントが単一サーバに接続する場合の構成 リクエストキュー 実行順序制御 ライブラリ DB 名前・型解決 シンボル テーブル 最適化・ライブラリ選択 データ構造・データ分散解決 ライブラリはリンクして使うという固定観念を捨て、 (1) データを預け、(2) 計算を依頼し、(3) 必要なとき に結果を取り寄せるというアプローチをとることで、 多様な計算環境で多数のライブラリを手軽に使える可 能性を示した。またそのようなシステムが、逐次環境 （１台のマシンあるいは２台のマシン）、並列環境（共 有、分散）で実装できることを示した。ユーザプログ ラムからみた相手先は仮想化されているので、 Grid 環境であっても理論的には問題ないはずである。 これまで、ライブラリはアルゴリズムの詳細を隠し てユーザに提供するとか、限られた環境でユーザプロ グラムに対する影響を最小限にしつつ高速性を提供し てきたが、現在では１種類のライブラリで済むでなく、 一人のユーザが利用する計算環境も１台の PC からク ラスタまで多岐にわたる。しかもコンピュータハード ウェアの命は短く、プログラムの寿命は長くなってい く。個々の環境に対するオーバーヘッドによるリソー スや性能のロスを許容し、 SILC のような仕組みを活 用して労力を別の活動に向けるべきではなかろうか？ ラッパールーチン ライブラリルーチン 図5 SILC サーバの実行スレッドの構成方式 き命令を一つ選び出す。次の「名前・型解決」ユニット は、まずライブラリデータベースから関数や手続きの 引数に関する情報を参照する。さらにシンボルテーブ ルを参照し、識別子にバインドされたデータを取り出 し、型やサイズを確定する。次に「最適化・ライブラ リ選択」ユニットがライブラリデータベースを参照し、 演算の内容や順序の最適化および適切なライブラリの 選択を行う。SILC は複合的なライブラリコレクショ ンを統合することを想定しているため、ライブラリご とに想定しているデータ構造やデータ分散が異なると 考えられる。そこで「データ構造・データ分散解決」 ユニットが使用するライブラリルーチンに適するよう に必要に応じてデータ構造やデータ分散を調整・変換 する。そしてライブラリルーチンは、インタフェース を統一するために各ルーチンにかぶせられたラッパー ルーチンを経由して呼び出される。 多くのライブラリを容易に取り込めるよう、ライブ ラリルーチンにかぶせるラッパールーチンはごく簡単 なもので済むように設計する。何らかの記述言語を準 備して、ラッパールーチンとライブラリデータベース のための情報を半自動的に生成することも検討してい る。これらのインタフェースは公開して、プロジェク ト外部で SILC 対応のライブラリを提供したり、ユー ザが独自のルーチンを追加したりすることもできるよ うにする計画である。 謝辞 本研究は，科学技術振興機構 (JST) 戦略的 創造研究推進事業 (CREST) 「大規模シミュレーショ ン向け基盤ソフトウェアの開発」プロジェクトの一部 として実施した． 参 考 文 献 1) 村田健郎，小国力，三好俊郎，小柳義夫編著: 工 学における数値シミュレーション，丸善 (1988). 2) 山本喜一, 榊原進, 野寺隆志, 長谷川秀彦: これだ けは知っておきたい数学ツール, 共立出版 (1999). 3) 長谷川里美他訳: 反復法 Templates, 朝倉書店 (1996). 4) http://www.cca-forum.org/ 5) Blackford, L. et al., ScaLAPACK Users’ Guide, SIAM, Philadelphia, Pennsylvania(1997). 6) Piotr Luszczek and Jack Dongarra: Design of Interactive Environment for Numerically Intensive Parallel Linear Algebra Calculations, ICCS 2004, Krakow Poland.