(57)【特許請求の範囲】
【請求項１】
複数のプロセッサが協調して処理を進める並列分散処理システムにおいて，
前記プロセッサは，
各プロセッサに特有の命令コード群で記述されたネイティブ・コードのライブラリを格納するライブラリ格納手段と，
各プロセッサに共通の書式で記述されたプログラムである仮想コードを解釈し実行する仮想コード実行手段と，
仮想コードの実行においてネイティブ・コードの呼び出しを検出したときに，前記ライブラリ格納手段に格納されたネイティブ・コードのライブラリを動的にリンクする動的リンク手段と，
他のプロセッサに仮想コードを実行させる場合に，実行させる仮想コードおよびその仮想コードと動的リンクに必要な対象とするネイティブ・コード・ライブラリの格納場所情報とを他のプロセッサに送信する手段とを備える
ことを特徴とする並列分散処理システム。
【請求項２】
複数のプロセッサが協調して処理を進める並列分散処理システムにおいて，
前記プロセッサは，
各プロセッサに特有の命令コード群で記述されたネイティブ・コードのライブラリを格納するライブラリ格納手段と，
各プロセッサに共通の書式で記述されたプログラムである仮想コードを解釈し実行する仮想コード実行手段と，
他のプロセッサに仮想コードを実行させる場合に，実行させる仮想コードおよびその仮想コードと動的リンクに必要な対象とするネイティブ・コード・ライブラリの格納場所情報とを他のプロセッサに送信する手段と，
他のプロセッサから仮想コードを受信し，その仮想コードを実行する場合に，前記ライブラリ格納手段に格納されたネイティブ・コードのライブラリを一括して動的にリンクする動的リンク手段とを備えた
ことを特徴とする並列分散処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は，複数のプロセッサが協調して処理を進める並列分散処理システムに関する。
【０００２】
現在の並列分散処理の環境は，それ自身の複雑さおよび並列処理のためのプログラミングの困難さから一部の専門家の独占物となってしまっているが，単一のＣＰＵによる処理のボトルネックが顕在化している現在，一般の計算機ユーザにも容易で高性能な並列処理を可能とする環境の提供が急務となっている。
【０００３】
【発明が解決しようとする課題】
複数のプロセッサが協調して処理を進める並列処理分散システム，特に，ＬＡＮ，ＷＡＮ環境でヘテロジーニァスな複数のプロセッサを１クラスタとして協調させながら一つのタスクを並列分散処理させるようなシステム環境が考えられている。このような並列処理環境を一般ユーザに提供する際に問題となるのは，簡易性と習得のし易さとであるが，これは性能との間にトレードオフの関係を生ずる。
【０００４】
従来の技術水準では，性能のために簡易性をかなりの程度犠牲にするか，または簡易性のために大幅な性能の低下を甘受せざるを得ない。
性能に関し，プロセッサ間のデータ転送の遅延とスループットが問題になるが，これは，本質的にはデータ転送の遅延の問題に還元できる。並列度の高い計算では，転送するデータの単位が小さく，転送量に関係のない転送回数だけに依存する遅延が主だからである。転送回数に依存する遅延を全体として減らすためには，転送するデータをある程度バッファに蓄積しておいて，まとめて一度に転送する必要があるが，このバッファの大きさをどの程度にすると最適であるのかは，因子が複雑に絡み合っているため，事実上実験してみないことには分からない。
【０００５】
また，プログラムを並列実行するためには，それを並列実行の単位に分割しなければならない。しかし，より小さな単位に分割すればそれだけ多くのＣＰＵが利用可能になる代わりに，実行の単位が小さくなることによる同期のオーバヘッド，コンテキスト・スイッチの増加によるオーバヘッド，データの遅延，データ転送量の増加，メモリのフラグメンテーションによるページングの増加等を招くことになり，ここでもまた，トレードオフを生じる。
【０００６】
エンドユーザに対しても並列処理によるプログラムの高速化，大規模化のメリットを享受できるようにすることが望まれているが，現状では，ある程度の性能を得るためには，エンドユーザでもエキスパート・ユーザの持つ並列処理の煩雑なノウハウを獲得してプログラムのチューニングをしなければならないという矛盾に直面する。
【０００７】
これらの解決の手段として，従来，並列処理のための高級言語，例えば，手続き型として，Ｏｃｃａｍ（Ａ．Ｂｕｒｎｓ，  ＰＲＯＧＲＡＭＭＩＮＧ  ＩＮ  ｏｃｃａｍ  ２，  Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，１９８８），  ＨＰＦ（Ｈｉｇｈ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｆｏｒｔｒａｎ  Ｆｏｒｕｍ，  Ｈｉｇｈ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｆｏｒｔｒａｎ  Ｌａｎｇｕａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，  １９９４），関数型として，ＣＬＥＡＮ（Ｒ．Ｐｌａｓｍｅｉｊｅｒ  ａｎｄ  Ｍ．ｖａｎ  Ｅｅｋｅｌｅｎ，  Ｆｕｎｃｔｉｏｎａｌ  Ｐｒｏｇｒａｍｍｉｎｇ  ａｎｄ  Ｐａｒａｌｌｅｌ  Ｇｒａｐｈ  Ｒｅｗｒｉｔｉｎｇ，  Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，１９９３），論理型として，ＰＡＲＬＯＧ（Ｔ．Ｃｏｎｌｏｎ，  Ｐｒｏｇｒａｍｍｉｎｇ  ｉｎ  ＰＡＲＬＯＧ，  Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，１９８９）のような高級言語が開発されている。
【０００８】
また，高レベルのライブラリ・インタフェースとして，例えばＰＶＭ（Ａ．Ｇｅｉｓｔ，Ａ．Ｂｅｇｕｅｌｉｎ，Ｊ．Ｄｏｎｇａｒｒａ，Ｗ．Ｊｉａｎｇ，Ｒ．Ｍａｎｃｈｅｋ  ａｎｄ  Ｖ．Ｓｕｎｄｅｒａｍ，  ＰＶＭ：Ｐａｒａｌｌｅｌ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  −  Ａ  Ｕｓｅｒｓ’  Ｇｕｉｄｅ  ａｎｄ  Ｔｕｔｏｒｉａｌ  ｆｏｒ  Ｎｅｔｗｏｒｋｅｄ  Ｐａｒａｌｌｅｌ  Ｃｏｍｐｕｔｉｎｇ  −，  ＭＩＴ  ｐｒｅｓｓ，１９９４  ），ＭＰＩ（Ｍｅｓｓａｇｅ  Ｐａｓｓｉｎｇ  Ｉｎｔｅｒｆａｃｅ  Ｆｏｒｕｍ，  ＭＰＩ：  Ａ  Ｍｅｓｓａｇｅ−Ｐａｓｓｉｎｇ  Ｉｎｔｅｒｆａｃｅ  Ｓｔａｎｄａｒｄ，  Ｍａｙ  ５，１９９４）が開発されている。
【０００９】
しかし，高級言語では十分な性能がでないか，性能を出すためにはエキスパート並みのノウハウが必要であり，また，高レベルのライブラリは，未だにエンドユーザが使えるようなレベルに達していない。
【００１０】
他の中間的な解決手段として，比較的低レベルの手続き型の逐次言語と並列処理のための命令言語を組み合わせる方法（Ｉ．Ｆｏｓｔｅｒ，  Ｒ．Ｏｌｓｏｎ  ａｎｄ  Ｓ．Ｔｕｅｃｋｅ，  Ｐｒｏｄｕｃｔｉｖｅ  Ｐａｒａｌｌｅｌ  Ｐｒｏｇｒａｍｍｉｎｇ，  Ｓｃｉｅｎｔｉｆｉｃ  Ｐｒｏｇｒａｍｍｉｎｇ，  Ｖｏｌ．１，ｐｐ．５１−６６，  １９９２；  Ｌ．Ａ．Ｃｒｏｗｌ  ａｎｄ  Ｔ．Ｊ．ＬｅＢｌａｎｃ，  Ｐａｒａｌｌｅｌ  Ｐｒｏｇｒａｍｍｉｎｇ  ｗｉｔｈ  Ｃｏｎｔｒｏｌ  Ａｂｓｔｒａｃｔｉｏｎ，  ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｌａｎｇｕａｇｅｓ  ａｎｄ  Ｓｙｓｔｅｍｓ，  Ｖｏｌ．１６，Ｎｏ．３，ｐｐ．５２４−５７６，  １９９４）が提案されている。
【００１１】
これらの方法は，全ての面にわたってエンドユーザであるのではなく，逐次処理のエキスパートであるが並列処理に関しては比較的エンドユーザに近い人を対象として，低レベルの逐次言語のチューニングと並列処理のチューニングとを分離し，並列処理のインタフェース部分だけに簡易で画一化されたチューニング・スタイルを導入するものである。
【００１２】
本発明が対象とするシステムは，後者の考え方にもとづくものであるが，並列処理インタフェース部分のさらなる画一化とエキスパート・ユーザのための汎用性とを推進し，逐次処理部分とのインタフェースに柔軟性を持たせるために，全体を手続き型言語の意味論で統一することを図っている。
【００１３】
例えば，ネットワーク上のワークステーション群あるいは専用のマルチＣＰＵの並列計算機上で並列処理プログラムを開発する場合，通常，ワークステーションを１台だけ使って，あるいは１台のワークステーション上に構築された並列計算機のシミュレータを使って，プログラムを開発するところから始める。また，多くの場合，過去に開発されたプログラムのためのルーティンがライブラリ化されているので，利用可能なライブラリが既に存在すれば，それを再利用するところからプログラムの開発を始める。
【００１４】
このようにしてプログラムの開発が進み，実際にプログラムを実行して全体のデバッグをする段階において，従来は，新たに開発したルーティンの部分に既存のライブラリをリンクしてできるバイナリのコードを，実行時に全てのワークステーション，あるいは全てのＣＰＵに毎回転送することを繰り返していた。この方法では，デバッグを必要としないライブラリの部分までデバッグの度に毎回転送することになり，プログラム開発の効率を下げてしまうという問題があった。また，実際にプログラムを実行して運用する段階においても，同様にライブラリの部分を毎回転送するので，プログラムの起動に掛かる時間が長くなってしまう要因となっていた。
【００１５】
特に，ネットワーク上のワークステーション群を使って処理を行う場合，異なったタイプのワークステーションを使用したいという要求もある。この場合，一つのアプローチとしては，例えば前述したＰＶＭ，ＭＰＩ等の並列処理のメッセージ・パッシング・インタフェースを使って機能単位で逐次処理の部分プログラムを作り，その間を通信によって結び付けて並列処理させる方法がある。この方法では，各プログラムのネィテイブ・コードはワークステーションのタイプごとに違っていても構わない。しかし，ワークステーションのタイプごとに，プログラムをコンパイルしてネイティブ・コードを作成しなければならず，作業が煩雑になるという欠点がある。
【００１６】
他のアプローチとしては，仮想コードを設定して，そのインタプリタを各々のワークステーションに配して並列処理させる方法がある。この方法は１種類のコードしか使用しないので，コンパイルその他の作業が単純であるという利点があるが，仮想コードの実行時におけるインタプリートにかかるオーバヘッドが大きいという欠点がある。
【００１７】
この欠点を克服する方法として，仮想コードからネィティブ・コードを呼び出すインタフェースを設けて，ネイティブ・コードの部分の実行によってインタプリートのオーバヘッドを低減させる方法がある。しかし，この方法はインタプリタに予め標準的なネイティブ・コード・ライブラリをリンクさせておくものであり，ユーザの作成した一般のネイティブ・コードをリンクして使用できるわけではない。
【００１８】
本発明は上記問題点の解決を図り，エンドユーザが容易に並列分散計算を記述できる環境を提供するとともに，仮想コードからの柔軟なネイティブ・コードの利用を可能にすることにより高性能なプログラム実行環境を実現することを目的としている。
【００１９】
【課題を解決するための手段】
図１は，本発明の並列分散処理システムの原理説明図である。
図１において，プロセッサ１０，１０’は，それぞれ仮想コード実行手段１１，１１’，ライブラリ・テーブル１３，１３’，動的リンク手段１４，１４’，ネイティブ・コード・ライブラリ１５，１５’，スケジューラ１６，１６’を備える。プロセッサ１０，１０’上で動作するプログラム１２，１２’は，各プロセッサ１０，１０’に共通の書式（構文）で記述された仮想コードと，各プロセッサ１０，１０’に特有の命令コード群で記述されたネイティブ・コードとからなる。
【００２０】
本発明では，ネットワーク２０上で複数のプロセッサ１０，１０’が協調して一つの計算を進めるようなユーザのプログラムを，各プロセッサ１０，１０’に共通の書式で記述された仮想コードと，各プロセッサ１０，１０’に特有の命令コード群で記述されたネイティブ・コードからなるネイティブ・コード・ライブラリ１５，１５’とに分離し，仮想コードの実行に必要なネイティブ・コード・ライブラリ１５，１５’は，各プロセッサ１０，１０’において動的リンク手段１４，１４’により仮想コードに動的にリンクする。ネイティブ・コード・ライブラリ１５，１５’は，それぞれローカルなファイルシステムに保存される。
【００２１】
仮想コード実行手段１１，１１’は，それぞれプログラム１２，１２’の仮想コードを解釈し実行する手段である。仮想コードの実行中に，まだプログラム１２，１２’中にマッピングされていないネイティブ・コードの呼び出しを検出すると，そのネイティブ・コード・ライブラリ１５，１５’を動的リンク手段１４，１４’によってマッピングし，仮想コード実行手段１１，１１’中のネイティブ・コード・インタフェースによってネイティブ・コードを実行する。
【００２２】
ライブラリ・テーブル１３，１３’は，動的リンク手段１４，１４’がネイティブ・コード・ライブラリ１５，１５’のマッピングを行って動的にリンクする場合に，対象とするネイティブ・コード・ライブラリ１５，１５’の格納場所情報を得るためのテーブルである。
【００２３】
スケジューラ１６，１６’は，プログラム１２，１２’を実行する単位であるプロセス（またはスレッド）に対してＣＰＵ実行権を与える制御を行う手段であり，他のプロセッサと通信を行いながら仮想コード実行手段１１，１１’を制御する。また，負荷分散等のために，プロセス（またはスレッド）を他のプロセッサとの間で送受するマイグレート（移動）の機能を持つ。
【００２４】
例えば，プロセッサ１０のスケジューラ１６がプロセス（またはスレッド）を他のプロセッサ１０’にマイグレートする場合には，スケジューラ１６は，仮想コードの部分と動的リンクに必要な情報，例えばライブラリ・テーブル１３を送り，ネイティブ・コードの部分は送らない。マイグレート先のプロセッサ１０’では，受け取った仮想コードを仮想コード実行手段１１’により先頭の実行開始点または実行中断点から実行し，仮想コードの実行においてネイティブ・コードの呼び出しを検出すると，動的リンク手段１４’によりプログラム１２’にネイティブ・コード・ライブラリ１５’をマッピングして実行を進める。
【００２５】
仮想コード実行手段１１，１１’による仮想コードの実行においてネイティブ・コードの呼び出しを検出したときに，ネイティブ・コード・ライブラリ１５，１５’を動的にリンクする代わりに，スケジューラ１６，１６’間でプロセス（またはスレッド）のマイグレートを行い，スケジューラ１６，１６’が他のプロセッサから仮想コードと動的リンクに必要な情報を受け取ったときに，最初にまとめて一度にネイティブ・コード・ライブラリ１５，１５’を動的にリンクするようにしてもよい。
【００２６】
【発明の実施の形態】
本発明に係る並列分散処理システムでは，並列化が容易で高性能な実行環境を提供するために，例えばネットワーク化されたヘテロジーニァスなクラスタ上で，実行中の任意のプロセスを適度にマイグレート（移動）させながら全体の処理を進めることを可能にすることと，ネットワーク上のプロセス間を高速なストリーム通信で結び付けることを実現する。
【００２７】
すなわち，あるプロセスが通信の応答を待っている時間にＣＰＵを他のプロセスの処理に割り当てることで，ＣＰＵの利用効率を上げると共に，他のプロセスの実行による通信をも時間的にオーバラップさせて全体として平均した場合の通信のレイテンシを低下させることを可能とするシステムの提供を実現する。
【００２８】
本発明の実施の一形態として，ネットワーク上のタイプの違う複数のワークステーションで並列計算用のインタプリタを起動し，その間に仮想コードと動的（ダイナミック）リンクに必要な情報を送り，ネイティブ・コードのライブラリを使って並列計算させる場合を説明する。
【００２９】
マスタプロセッサ，スレーブプロセッサに対応するものを，特定のシステムでのプロセスとして実現し，その内部で複数の仮想コード・インタプリタをスケジューリングしながら実行するようにし，このプロセスにより，ワークステーション間で入出力データ，仮想コード，ライブラリ・テーブル，インタプリタの制御情報，その他を通信する。
【００３０】
（１）要求駆動方式
図２は，本発明の実施の一形態である要求駆動方式による実現例を示す図である。図２において，プロセッサ３０は，ダイナミック・リンカ３２およびネイティブ・コード・インタフェース３３を持つインタプリタ３１，仮想コードで記述されたプログラム３４，動的リンクの情報を格納し，ルックアップするためのライブラリ・テーブル３５，ローカル・ファイルシステムに格納されたネイティブ・コード・ライブラリ３６，他のプロセッサと通信を行いながらインタプリタ３１を制御するスケジューラ３７を備える。インタプリタ３１は，図１に示す仮想コード実行手段１１および動的リンク手段１４に対応する。プロセッサ３０’の構成も同様である。
【００３１】
ここで，プロセッサ３０からプロセッサ３０’へプロセスを移動させる事象が発生したとする。この事象は，ユーザの明示的な移動指示によるものでも，負荷分散制御によりスケジューラ３７が自律的に生じさせるものでもよい。プロセッサ３０のスケジューラ３７は，プログラム３４中の仮想コードとライブラリ・テーブル３５をプロセッサ３０’へ転送する。プロセッサ３０’のスケジューラ３７’は，プロセッサ３０から上記の情報を受け取り，プログラム３４’，ライブラリ・テーブル３５’としてメモリ上に設定する。
【００３２】
ここで，ネイティブ・コードの呼出命令は，呼び出す関数名を「ｆｕｎｃ」とすると，「ｌｉｂ＿ｃａｌｌ  ”ｆｕｎｃ”」である。関数名ｆｕｎｃの関数を含むライブラリを格納するファイル名を，ここでは「／ｏｐｔ／Ｘ１１／ｌｉｂ／ｌｉｂＸ１１．ｓｏ」とする。
【００３３】
インタプリタ３１’は，プログラム３４’の仮想コードを実行し，ネイティブ・コードの呼出命令「ｌｉｂ＿ｃａｌｌ  ”ｆｕｎｃ”」を検出し，呼び出す関数名ｆｕｎｃを取り出す。これが，後で説明するハッシュ・テーブルに登録されていれば，それを使って直接ネイティブ・コード・インタフェース３３’で関数名ｆｕｎｃの関数を実行する。ハッシュ・テーブルに登録されていない場合には，ダイナミック・リンカ３２’を起動し，ライブラリ・テーブル３５’に登録してあるライブラリ名から，「／ｏｐｔ／Ｘ１１／ｌｉｂ／ｌｉｂＸ１１．ｓｏ」のローカル・ファイル中の対応するネイティブ・コード・ライブラリ３６’の中身をアクセスし，関数名のハッシュ・テーブルを構築し，これをライブラリ・テーブル３５’のライブラリ名と結合する。
【００３４】
関数名ｆｕｎｃの関数が見つかるまでライブラリのハッシュ・テーブルの構築を続け，ｆｕｎｃが見つかったときには，ｆｕｎｃを含むライブラリをプログラム３４’中のネイティブ・コードの記憶領域にマッピングし，そのライブラリが利用しているその他の標準ライブラリとリンク・エディットし，ハッシュ・テーブルに各関数のエントリ・ポイントを登録し，そのライブラリの各関数を実行可能な状態にする。
【００３５】
最後にネイティブ・コード・インタフェース３３’を使って，ｆｕｎｃに対応するライブラリ関数のエントリ・ポイントを検索し，その関数を実行する。
図３は，図２の構成例による要求駆動方式の処理フローチャートである。
【００３６】
図２に示すプロセッサ３０がマスタＣＰＵ，プロセッサ３０’がスレーブＣＰＵであったとする。プロセッサ３０’が，最初何も処理するプロセス（スレッド）がない状況であったところに，図３のステップＳ１１において，マスタのプロセッサ３０からプロセス（スレッド）のマイグレートがあると，処理を開始する。
【００３７】
まず，ステップＳ１２では，仮想コードとライブラリ・テーブルをマスタのプロセッサ３０から受信する。ステップＳ１３では，インタプリタ３１’により，受け取った仮想コードを実行する。実行の結果，ステップＳ１４によりネイティブ・コード・ライブラリ呼び出し命令を検出した場合には，ステップＳ１５の処理へ進み，実行終了を指示するｅｘｉｔ命令を検出した場合には処理を中止する。その他の命令である場合には，ネイティブ・コード・ライブラリ呼び出し命令またはｅｘｉｔ命令のいずれかを検出するまで，ステップＳ１３〜Ｓ１４を繰り返す。
【００３８】
ステップＳ１５では，インタプリタ３１’は，該当するネイティブ・コード・ライブラリ３６’がマッピングされているかどうかを，関数名のハッシュ・テーブルをもとに判定する。ネイティブ・コード・ライブラリ３６’がマッピングされていなければ，ステップＳ１６の処理を行い，ネイティブ・コード・ライブラリ３６’がマッピングされていれば，ステップＳ１７の処理へ進む。
【００３９】
ステップＳ１６では，ライブラリ・テーブル３５’からマッピングするネイティブ・コード・ライブラリ３６’のファイル名を得て，ダイナミック・リンカ３２’により，そのネイティブ・コード・ライブラリ３６’をマッピングし，リンク・エディットを行う。
【００４０】
その後，ステップＳ１７では，インタプリタ３１’のネイティブ・コード・インタフェース３３’に制御を渡してネイティブ・コードを実行する。ネイティブ・コードの実行が終了したならば，ステップＳ１３へ戻り，同様に仮想コードの実行を続ける。
【００４１】
（２）前処理方式
図４は，本発明の実施の一形態である前処理方式による実現例を示す図である。図４に示す実現例は，図２に示す実現例とほぼ同じ構成であるが，ダイナミック・リンカ５４，５４’がインタプリタ５１，５１’内ではなく，スケジューラ５３，５３’の内部にある点が相違する。
【００４２】
マスタのプロセッサ５０から仮想コードとライブラリ・テーブルを転送し，スレーブのプロセッサ５０’が受信するところまでは前述の要求駆動方式と同様である。しかし，この方式では，スレーブのプロセッサ５０’がマスタのプロセッサ５０から仮想コードとライブラリ・テーブルとを受信した後，インタプリタ５１’を起動する前に，受信したライブラリ・テーブル５６’の全てのライブラリについて関数名のハッシュ・テーブルをあらかじめ作り，ライブラリをプログラム５５’のネイティブ・コードの記憶領域にマッピングし，標準ライブラリなどとともにリンク・エディットし，ハッシュ・テーブルにライブラリ関数のエントリ・ポイントを登録する処理を最初にまとめて行う。
【００４３】
インタプリタ５１’は，プログラム５５’の仮想コードを実行し，ネイティブ・コードの呼び出し命令「ｌｉｂ＿ｃａｌｌ  ”ｆｕｎｃ”」を検出すると，直接ネイティブ・コード・インタフェース５２’を起動して，ネイティブ・コードで作成された関数ｆｕｎｃを実行する。
【００４４】
図５は，図４に示す構成例による前処理方式の処理フローチャートである。
図４に示すスレーブのプロセッサ５０’が，最初何も処理するプロセス（スレッド）がない状況であったところに，図５のステップＳ２１において，マスタのプロセッサ５０からプロセス（スレッド）のマイグレートがあると，処理を開始する。ステップＳ２２では，プロセッサ５０’は，仮想コードとライブラリ・テーブルをマスタのプロセッサ５０から受信する。
【００４５】
次に，ステップＳ２３では，スケジューラ５３’内のダイナミック・リンカ５４’により，受信したライブラリ・テーブル５６’に登録された全てのネイティブ・コード・ライブラリ５７’をマッピングし，リンク・エディットを行う。
【００４６】
ステップＳ２４では，インタプリタ５１’により仮想コードを実行する。実行の結果，ステップＳ２５により，ネイティブ・コード・ライブラリ呼び出し命令を検出した場合には，ステップＳ２６の処理へ進み，実行終了を指示するｅｘｉｔ命令を検出した場合には処理を中止する。その他の命令である場合には，ネイティブ・コード・ライブラリ呼び出し命令またはｅｘｉｔ命令のいずれかを検出するまで，ステップＳ２４〜Ｓ２５を繰り返す。
【００４７】
ステップＳ２６では，インタプリタ５１’のネイティブ・コード・インタフェース５２’に処理を渡してネイティブ・コードを実行する。ネイティブ・コードの実行が終了したならば，ステップＳ２４へ戻り，同様に仮想コードの実行を続ける。
【００４８】
入力データなどに依存して実行時に様々なライブラリが使用され，ライブラリの登録数が多い割には実行時に使用されるライブラリの数が少ない場合には，図２に示す要求駆動方式のほうが有利である。
【００４９】
一方，実行時に登録されたほとんどのライブラリがプロセッサに使用される場合には，図４に示す前処理方式のほうが，個々のネイティブ・コード呼び出し命令でライブラリが既にマッピングされているかどうかをチェックする必要がないので有利である。
【００５０】
【発明の効果】
本発明によれば，中間コードとしての仮想コードと，各プロセッサに特有のネイティブ・コードとを分離し，仮想コードの実行時または仮想コードの受信時に，ネイティブ・コードを動的にリンクする仕組みを設けることにより，ヘテロジーニァスな複数のプロセッサ間においても，並列処理の処理速度の高速性を保持し，かつ，エンドユーザの使用にも適した平易な並列分散処理システムの提供が可能となる。
【００５１】
例えば，ネットワーク上のワークステーション群あるいは専用のマルチＣＰＵの並列計算機上で並列処理プログラムを開発する場合，システムの標準ライブラリ，他で既に開発を終えたユーザ作成のライブラリ，デバッグが終了したユーザ作成のライブラリ等を更新する必要がない。
【００５２】
また，各プロセッサに特有のネイティブ・コードをマスタのプロセッサから毎回実行の度に，あるいは実行に先立って転送する必要がないので，デバッグその他の開発作業が軽減され，開発が迅速になる。また，開発が終了し，実際にプログラムを起動して使用するときにも，プログラムの起動時間が短縮されるという効果を奏する。
【００５３】
さらに，プログラムを変更する場合，仮想コードの部分のみの変更によりプログラム全体としての変更を柔軟に吸収し，ネイティブ・コード・ライブラリを利用することで性能を引き出すことが可能となるため，チューニングや保守が容易になるという効果を奏する。
【図面の簡単な説明】
【図１】本発明の原理説明図である。
【図２】本発明の実施の一形態である要求駆動方式による実現例を示す図である。
【図３】要求駆動方式による処理フローチャートである。
【図４】本発明の実施の一形態である前処理方式による実現例を示す図である。
【図５】前処理方式による処理フローチャートである。
【符号の説明】
１０，１０’  プロセッサ
１１，１１’  仮想コード実行手段
１２，１２’  プログラム
１３，１３’  ライブラリ・テーブル
１４，１４’  動的リンク手段
１５，１５’  ネイティブ・コード・ライブラリ
１６，１６’  スケジューラ
２０          ネットワーク
【図１】
0003628782.tif 000002
【図２】
0003628782.tif 000003
【図３】
0003628782.tif 000004
【図４】
0003628782.tif 000005
【図５】
0003628782.tif 000006