みかログ

こちらで引用されているのを発見したのでコメントしてみます．

forkするみたい。pipeでやってるのかな。いずれにしろここがボトルネックか。。。

erlang-C ffiを作ろうとしている

erl_ddllの場合はforkはしない（ハズ）です．

なぜここがボトルネックになるかというと，

・ドライバと通信するのは load_driver したプロセスが行う（のが普通？）
・そうすると，他のプロセスは load_driver したプロセスを仲介して通信する必要がある
・すべての通信が1つのプロセス（のメッセージキュー）を中継する

中継プロセスのメッセージキューに複数のプロセスがメッセージを書き込むので，ここがボトルネックになります．
Erlangのメッセージキューは，キューが長くなるほどパフォーマンスが低下します．
処理が間に合わずキューに貯まれば，パフォーマンスが落ちて，更にキューが貯まる…という悪循環になってしまいます．
（R12Bの頃に確認した限りでは．R13Bではもしかしたら改善しているかも）

と，改めてマニュアルを読むと，Portを外部に出しておいて，直接ポートドライバにメ ッセージを送るようにして，返事を driver_send_term で送り返せば上記の問題は緩和するかも…．
とはいえ，やっぱりポートドライバ上にはメッセージキューがあると思われるので，そこがボトルネックになりそうな気はします．

port_control だと直接呼び出せるようなので，これを使って呼び出し元のプロセスが直接呼び出せば，上記のメッセージキューのボトルネックも回避できるのかも．

この場合，SMPを有効にしてあれば，SMPのスレッド数分は同時にポートドライバの関数がコールされるのではないか…と推測しますが未確認です．

% 確か前に試して何かうまくできなかった気がするけど，詳しく覚えてなく(^^;

driver_outputという関数で返す。→　メモリ領域の解放はどうなるんだろう？

erlang-C ffiを作ろうとしている

driver_alloc で確保して，driver_output_term とかで結果を送った後，driver_free ですね．
メッセージとして送ったときにコピーされます．

みかログに載っているコードをコピってテストしてみたところ、10倍からは随分改善されたけど、マルチコアの優位性を使い切れていない。チューニングの問題なのかどうなのか。

erlang-C ffiを作ろうとしている

徐々に改善していくとは思いますが，排他制御のオーバーヘッドがあるのである程度仕方ないかなという気は…．
プロセス間の通信をこんなに大量にやらなければ，SMPでちゃんと速くなりますが，アプリケーション特性によっては -smp disable の方が良いこともあるようです．
ある程度はメッセージの通信量を減らすとか，自分で努力しないとダメかもしれません．
（OTPで組むと，gen_*系とかメッセージいっぱい使うので，個人的にはパフォーマンスで不利なんじゃないかと思って，普段は自前でサーバを書いていたりしますが，正しいかは未検証）

ただ，R13Bでもかなり大幅な改善があったので，今後も期待できるとおもいます．たぶん．．．