2011-12-08 12 views
1

私のC++コード(my_app)では、Fortran(lib_fort)で書かれたライブラリ(DLL)を動的に読み込む外部アプリ(app_ext)を起動する必要があります。このライブラリ(lib_fort)から、my_appからいくつかのメソッドを同期的に呼び出す必要があります。 >(app_ext)--loads - - >(lib_fort) - "呼び出し" - >(MY_APP)FortranへのC++呼び出し

app_extに開発されていない (MY_APP)--launches:だから、そのようなが

私によって。

あなたはそれを行う方法、そして最も重要なことは何ですか、それを効率的に行いますか?

編集:

明確化。外部アプリ(app_ext)を起動し、そこからライブラリ(lib_fort)をロードすると、プログラムの実行全体で1回しか発生しません。その部分は超効率的である必要はありません。 lib_fortとmy_appの間の通信はパフォーマンス上重要です。 Lib_fortは何百万回もmy_appを呼び出す必要があります。

全体的に効率的なプロセス間通信です。 app_extを起動した後のMy_appロールは、lib_fortからの「呼び出し」を待機して提供することです。分散システムと共有メモリの両方の環境、つまり、単一ホスト(1)のmy_appとapp_ext + lib_fortと、異なるマシン(2)のmy_appとapp_ext + lib_fortの両方で動作する必要があるという難しい点があります。

私はMPIについて考えていましたが、2つの異なるアプリケーション間でMPIと通信することが可能かどうかはわかりません(シングル、マルチプロセス、MPIアプリケーションとは対照的です)。

おそらく、共有メモリを使用したプロセス間通信のシナリオでは? (または多分MPI?)

+0

アプリを起動してからdllを読み込むには、一定の時間がかかります。ファイルキャッシュのために2回目の処理が高速になります。できるだけ少ない回数でそれを行います。 –

+0

ありがとうございます。私は私の質問を明確にした。あなたが言及している部分はあまり重要ではありません - 私の最大の関心事はプロセス間通信です。 – garret

答えて

0

OK、本当の問題は、プロセス間の通信方法です。 COM(Component Object Model)やRPC(Remote Procedure Call)やパイプについて話しているかもしれませんが、その下にはソケットを使用しています。 IMEは、最も簡単で効率的な方法は、自分自身でソケット接続を開き、それらの上で会話することです。それはレートリミッタとなり、実際にはそれ以上のスピードはありません。

+0

ありがとう、私はMPIと間違った道を歩いていたようです。しかし、単一のマシンのシナリオはどうですか?ソケットもパフォーマンスに勝つだろうか?両方のケースのために単一の実装を持つことは魅力的です:) – garret

+0

@garret:私はそれを試してみるでしょう。ソケットはパイプのように動作し、OSはI/Oを待っているプロセスを目覚めさせてくれます。プロセス間通信の手段としては、最も効率的であると期待しています。不必要なコンテキストスイッチを使いこなすことはありません。基本的には、I/Oチャネルをほぼ100%ビジー状態に保つことができるはずです。スタックサンプルのほとんどがI/O待ちで表示されます。 IME、あなたがそれらのことをいかに速く進めることができるかは驚くべきことです。 –

関連する問題