1 つの関数 f :: ByteString -> ByteString を提供するクローズド ソースの非スレッド セーフ C++ 共有ライブラリがあります。この関数の実行時間は、1 秒から数時間です。
計算を複数のコア/サーバー (SIMD) に分散する方法を探しています。
一言で言えば、機能を提供するフレームワークを探しています
g :: Strategy b -> (a -> b) -> a -> b
シーケンシャルにしか呼び出せない関数を、Haskell の他の純粋な関数と同じように動作する関数に持ち上げます。
たとえば、次のように書けるようになりたいです。
parMap rwhnf f args -- will not work
f は FFI を介して非スレッド セーフ ライブラリで C 関数を呼び出すため、これは機能しません。したがって、関数 f を、ジョブ キューを保持し、タスクを N 個の個別のプロセスにディスパッチする関数 g に置き換えることができます。プロセスは、ローカルまたは分散で実行できます。
parMap rwhnf g args -- should works
私がすでに調べた潜在的なフレームワークは
MPI : クライアント (Haskell) <-- MPI --> ブローカー (C++) <-- MPI --> ワーカー (C++) <--> ライブラリ (C++)
ZeroMQ : クライアント (Haskell) <-- ZeroMQ --> ブローカー (C++) <-- ZeroMQ --> ワーカー (C++) <--> ライブラリ (C++)
Cloud Haskell : クライアント (Haskell) <-- CloudHaskell --> ワーカー (Haskell) <-- FFI --> Lib (C++)
ギアマン
Erlang : クライアント (Haskell) <-- Erlang --> ブローカー (Erlang) <-- Erlang C ノード --> ワーカー (C++)
それぞれのアプローチには長所と短所があります。
MPI は多くのセキュリティ問題を引き起こし、かなり重いソリューションです。
ZeroMQ は優れたソリューションですが、ブローカー/ロード バランサーなどをすべて自分で作成する必要があります (特に、信頼性を正しくすることは簡単ではありません)。
CloudHaskell はあまり成熟していないように見えます。
Gearman は Windows では動作せず、Haskell バインディングもありません。java-gearman-service については知っていますが、C デーモンよりも成熟度が低く、他にもいくつかの問題があります (たとえば、doc がない、しばらくタスクの受信フローがない場合にシャットダウンするなど)。
1 に似ており、第 3 言語を使用する必要があります。
ありがとう!