第
11章
各プロセッサからのストリームからの受信処理を一本にするために、merge処理が増 大する．
組み込み述語mergeが提供されているが、merge処理のコストが高いことに変わり はない． 並列言語Occam でも複数ストリームからの入力処理を行うALTは非常に コストが高く、並列言語一般に効率的なプログラミングは難しいものと思われる．
KLICでは複数プロセスから一つのプロセスに向かうコミュニケーションについては、組
み込みmergeを提供することで、ある程度の効率的なサポートを実現している．また逆に
一つのプロセスから複数プロセスへのブロードキャストは、同じ共有変数を用いることで 実現できる．しかし複数プロセス間のコミュニケーションを行いたいと考えた場合には、プ ロセス間を直接結合するストリームを張るか、間にルーティングを行うネットワークをプ ロセスで構成するしかない．
プロセス間に直接つながるストリームを張るには、上のように配列構造のコピーが頻発 してしまい非効率である．従って、プロセスを節点として用いたルーティングネットワー クが実現可能性がある． 今回の実装では単純なリングネットワークを構成し、節点プロセ スを各物理プロセッサ上に置いた．これは、負荷の分散は論理的な隣接点にのみ送ること 想定したためであった．しかし、隣接点以外にも分散させたいと思えば、各要素プロセッ サ上にルーティング節点となるプロセスを置くのは、nCUBE2のよう物理的なネットワー クにルーティング機構が備わったシステムでは明らかに非効率である．プロセスを節点と して、適当なトポロジーの仮想的なネットワークを各プロセッサ上に構成し、節点プロセ スを通じて物理ネットワーク間を分散させることで、効率的なルーティングシステムが構 築できるものと思われる．
11.2
プログラム変換について
Instant Replayで提案された方法は、非決定性を含む述語でもログが発生する．非決定
的実行を含む決定的な実行もまた非決定的だとみなされるためである．実際上はログを送 るストリームを分岐させる必要性のためでもある．従って本方式にとって有利なプログラ ミングスタイルとしては、非決定的な実行が論理的な構造の上位レベルにあるものと言え る．このようなスタイルへの自動変換の可能性の検討も、今後の課題である．
11.3
非決定性の高いプログラムについての効率化
本研究で提案した耐故障プログラムが効率良く動作するためには、単体プロセッサでは、
プロセッサ上で行うコミュニケーション処理性能がプロセッサ内の単位処理性能よりも小 さい方が有理になる．コミュニケーション処理性能が大きい場合であっても、元のプログ ラムが並列実行に相応しい性質を備えているならば、並列実行によって理論上は効率化で きることを示したが、それでも単体での実行時間のプロセッサ台数分の1になるに過ぎな い．本実験で用いたシステムは、メッセージ処理にリダクション処理の最大で80倍以上か かるものであり、単体プロセッサでの性能はプログラム自身の非決定性の比率に頼るもの であった．
非決定性がプロセッサ間のコミュニケーション回数を増やすことが、性能低下の主な原 因である．しかしnCUBE2上のKLIC処理系では、バッチ転送モードのようにまとめて メッセージを転送することで効率化を図ることができる．従って非決定的実行に関するロ グ、返信についてパックして転送することができれば、非決定性が高くても、効率化の可能 性がある．一つのプロセスについてパックすることは信頼性を損なうことになるので、互 いに関係しないプロセスのログをパックすることで、効率化を図れるものと思われる． こ のようなログのパック転送についても、今後の課題である．
11.4
再構成について
本研究で提案する耐故障実行方式は、現在の実装ではプライマリサイトを構成するプロ セッサが1台故障しても、サイトを構成する他のプロセッサも放棄したままにしている．こ れら残りのプロセッサを有効利用するために、再構成の方法についても考察する必要があ る．再構成には、次の二つの可能性がある．
1. 動作中のプライマリサイト、バックアップサイトに組み入れる．
2. 一つのバックアップサイトとして構成し直す．
信頼性を向上させるには、2の方が望ましい．実現可能性は1が優勢であり、現在の実装 にも容易に組み込める．しかし、第5章で述べたように、この再構成手法に有意性はほと んど見られない．2の実現の困難さは、実行途中のプログラム状態を再現することにある．