前回はElixirでHTTPするコードを書いてみた。
mcommit.hatenadiary.com
mixを使えば比較的短い行数でHTTPアクセスするコードが書けることは分かったけど、これでは正直Elixir/Erlangの良さが分からない。
そもそもElixir/Erlangは並列計算にメリットがある言語とされている。どのようにそれが実現されているのかがよく分かっていない。
多分Elixir言語の勉強をこのまま続けても組み込みソフトの開発をメインでやっている自分には直接的(Elixirを活用するという意味で)なメリットを得られることはあまりなさそう。
せっかくならElixir/Erlangがどのように並列プログラミングのコンテキストを確立しているかを知っておいた方が今後のために意味がありそうな気がしてきた。
ということで勉強の主旨を変えてErlang/BEAMのレイヤーについて勉強してみることにする。飽きたら多分やめる。
参考資料
ビルドするときにも入手したが、Erlangのソースは、
https://www.erlang.org/downloads
で入手できる。tar.gz で80MBくらいある。
ソース構成は別途まとめてみるとして、
とりあえずErlangの言語処理系に関するコードは
otp_src_20.1/erts
に配置されている。
コードはどうも全てCで書かれているようだ。
一方でライブラリ類は、
otp_src_20.1/lib
に配置されているみたいだが、こちらのソースは全て拡張子が .erlになっているのでerlangで書かれているようだ。
参考書籍
そもそもElixirの勉強から始めたのでErlang言語についてもよく知らないので一応参考書籍を買ってみた。
中古だと多少なりと値段が下がっているので求めやすい。
※戦闘機本はだいぶ前に買ったけど数ページ読んでBOOK OFFに売った記憶がある。
戦闘機本には、ErlangのVMであるBEAMに関する説明はない。あくまでErlang言語としても解説書といった感じだ。
読んでわかったこと
スタックマシンではなくてレジスタマシンということは分かったがレジスタマシンのメリットはよく分かっていない。
そもそもVMである以上レジスタだのスタックだのと言ったところでどちらもメモリ上で実現されていることに変わりはないはずだ。
Erlangではレジスタの一部をCPUの物理的なレジスタに割り当てているとのこと。(文脈からすると386系だとEAXレジスタのことっぽい)
スケジューラの動作について
分かったことよりよく分からない事の方が多い。
少なくともR15では、スケジューラをコアに対して１つ割り当てるという方式だったようだ。
Erlangの設計者はマルチコアについてしっかりと熟知した上でErlangのスケジューラを実装しているというのはなんとなく伝わってきた。
H/Wを意識しながら言語を実装したとなると、Erlangの特性はOS依存になるということになる。
JLOUIS Ramblings: How Erlang does scheduling
の記事でも
Erlang usually has a thread per core you have in the machine. Each of these threads runs what is known as a scheduler. This is to make sure all cores of the machine can potentially do work for the Erlang system. The cores may be bound to schedulers, through the +sbt flag, which means the schedulers will not "jump around" between cores. It only works on modern operating systems, so OSX can't do it, naturally.
と書かれていた。
マルチコアの技術は、ムーアの法則に陰りが見えてから急激に進化しているようなので当然のようにも思える。
逆に言うとこれからの言語は、言語レベルでマルチコア化を意識していることが大きなメリットになるんだろう。
といっても組み込み界隈にマルチコア/並列特化言語でのプログラミングの時代が来るとは思えない。
だいぶ前にDUAL CORE のマイコンを使った開発をしたことがあったけど、基本的には互いのコアで何をしているかとか意識しなくてよい構造で作るのが正解だった気がする。
そもそもコア間で同期とかとったらマルチにしているメリットなんてない。
汎用OSだとコアをどう扱うかというのは難しいように思う。コア毎への最適なタスクの割り当てとかパッとイメージできない。設計しようとするとCPUに関するかなり膨大な知識が必要になるんじゃないだろうか。
その他(英語訳について)
訳がわからない単語とかちょくちょく出てくる。
コンピュータサイエンスの文脈では「生成する」の意味で使うことが多いみたい。
今まで意味を気にしてなかったけど、Rubyの yieldはブロックの処理を実行する機能なのでこれは、恐らく「明け渡す」「譲る」の意味なんだろう。
yielding だと「降伏する」という意味になるらしい。
日本語でもそうだけど、こういう１つの単語にいろんな意味を割り当てるのはやはりよくない気がする。
同じような例で、マイコンのマルチファンクションGPIOもバグがでやすい。何処がよくないのか調べるのも時間がかかる。
１単語＝１目的
がいい。
「なしで済ませる」「見合わせる」という意味。
forgoes throughput for lower latency.
は
低レイテンシによるスループットの低下
と訳すようだ。(Google翻訳による)
これもすぐにはピンとこなかった。
随時。
- a quite intricate process
かなり複雑なプロセス。
英語の翻訳は根性で乗り切るしかないな。
BEAM BOOKは丁寧に解説が書かれている印象があるが、ソースを軽く見たけど解説とソースとの対応関係が分からない。
もう少し、PDFの方を読んでからソースを見た方がいいかもしれない。
