Akka vs Erlang【スケジューラ編】

まっちゃら @ FOLIO @matsu_chara

なるほど？akka内部でブロックしたい場合はアクター単位でブロックするのは無理だけど、dispatcherを工夫すればブロックしてもExecutionContext的な物がことなるからThread.sleepをよんでも大丈夫そうという知見を得た

まっちゃら @ FOLIO @matsu_chara

普通のdispatcherでやると同じdispatcherを共有してる奴も（当たり前だけど）止まってしまうけどPinnedDispatcherを使えば1actor1threadになるから影響を受けなくはなる。 gist.github.com/matsu-chara/33…

まっちゃら @ FOLIO @matsu_chara

けど、アクターたくさん作りたい時にPinnedDispatcherは悪手だよなー(´･_･`)

まっちゃら @ FOLIO @matsu_chara

blockするアクターはtype = Dispatcherなdispatcherを専用で作って、min, maxともに大きめにする（どのくらいにするかは計測しろ）ってそもそも本に書いてあった(´･_･`)

Sotaro Kimura @kimutansk

@matsu_chara そのあたり、アクターモデルに限らない汎用的な定石ですからねぇ。　コネクションプーリングのサイズ設計／チューニングとかと似たようなノリになると思います。　逆にアクターモデルもその手のものからは逃れられないとわかってちょっと安心＾＾

まっちゃら @ FOLIO @matsu_chara

@kimutansk そうですね・・。Executor自体のチューニングとDispatcherTypeの選定を同時に行わないといけないっぽいのですごいハードル高い感じがします(´；ω；`)

Sotaro Kimura @kimutansk

@matsu_chara そうですね。粒度を細かくアクターとして切りだした結果、個々のアクターに対してそのあたりのチューニングを個別に行う必要が出てくるのは、アクターモデルの明確なデメリットだとは思います。メリットも多いんですけどね・・・

まっちゃら @ FOLIO @matsu_chara

@kimutansk　たしかにデメリットですね・・。　 VMレベルでメモリ分かれてるErlangとかだと要らないみたいなことがないかという淡い期待を抱いています(◞‸◟)

Sotaro Kimura @kimutansk

@matsu_chara いえ、多分ないですよ（汗　そのレイヤはプログラム言語とはまた別の話ですので。自動でチューニングしてくれるはあるかもしれませんが、それはまた別の話になりそうです。

まっちゃら @ FOLIO @matsu_chara

@kimutansk なるほど。社会は厳しいですね・・(◞‸◟)

おくみん@女子高校生 @okumin

@kimutansk @matsu_chara Erlang だと計算や nif 以外でスレッドがブロックされないので、基本的にはいらないと思います。

まっちゃら @ FOLIO @matsu_chara

@okumin なるほど、言語自体が並行・分散をやるために作られてるとエコシステムもそれにあったものが出てくる的な感じの良さですね…

Sotaro Kimura @kimutansk

@okumin @matsu_chara そうなんですか？ただ、IOが発生する場合など、どうしてもブロッキング処理は発生すると思うのですが、そのあたりはどう対応されているのでしょうか？

Yuta Okamoto @okapies

@kimutansk @okumin @matsu_chara 軽量スレッドだと、その辺は VM でよきに計らってくれるとかですかねぇ？

Sotaro Kimura @kimutansk

@okapies @okumin @matsu_chara ただそれだと同期書込み的な処理は出来きないか、またはOSのIO関連イベントを拾ってハンドリングしなくてはいけない読みにくいコードになるんですよね。あと、計算処理が重い場合はやはりスレッド数のチューニングは必要になる・・・

おくみん@女子高校生 @okumin

@kimutansk @matsu_chara @okapies ネットワークは多分ノンブロッキングIOで実装されているだろうし、ファイル IO も Erlang プロセスレベルではブロックされないようになってると思います。非同期 IO かスレッドプールかは分かりませんが……

おくみん@女子高校生 @okumin

@kimutansk @matsu_chara @okapies 計算が重い場合はプロセスプールみたいなものを作るしかなさそうですね……ただ私は Erlang に詳しくないので間違ってる可能性は大いにあります。

おくみん@女子高校生 @okumin

@kimutansk @matsu_chara @okapies IO スレッドがいるというカキコはありました…… stackoverflow.com/questions/2200…

まっちゃら @ FOLIO @matsu_chara

@okumin @kimutansk @okapies なるほど。もし性能が足りなくなってきたらrawモードにして自分でプロセスを用意するみたいな戦略でチューニングという感じですかね・・

Sotaro Kimura @kimutansk

@matsu_chara @okumin @okapies なるほど。IOを別出しにしたスレッドプールをVMレベルで持っていると。「このファイルの書込みが終わったら対応した応答メッセージを返す」の実現方法が気になりますが、それはepoll系システムコールを使うのか・・気になります

おくみん@女子高校生 @okumin

@kimutansk @okapies @matsu_chara これにたくさん書かれてました。結果の通知は単にファイル扱うプロセスに伝えてあげればいい気がします。 erlang.org/doc/man/file.h…

Sotaro Kimura @kimutansk

@okumin @okapies @matsu_chara 結果通知の際の「書込時のコンテキスト」をどう持ち越すか、が気になってましたが、Erlang側で呼び出す場合はメソッドの返り値見る限り同期的な書き方で扱えるわけですね。ただ、中身はスレッドプールによる非同期化がされていると

おくみん@女子高校生 @okumin

@kimutansk @matsu_chara @okapies Erlang はプロセスが receive を呼んだらメッセージが届くまで処理を中断して、届いたら処理の続きが実行される感じの動きをしますね。便利ですね。

Sotaro Kimura @kimutansk

@okumin @matsu_chara @okapies それは便利ですね。Java/ScalaだとFutureとか使わなければならない所を実行環境側で吸収してくれるのは非常にありがたい・・・

おくみん@女子高校生 @okumin

@kimutansk @matsu_chara @okapies Akka の中で Future を使うと、完了前に次のメッセージを処理しにいっちゃうので、本当に同期したいときは面倒です……