前回はElixirでHTTPするコードを書いてみた。
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言語についてもよく知らないので一応参考書籍を買ってみた。
- 作者: Fred Hebert,山口能迪
- 出版社/メーカー: オーム社
- 発売日: 2014/07/04
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (10件) を見る
- 作者: Joe Armstrong,榊原一矢
- 出版社/メーカー: オーム社
- 発売日: 2008/02/23
- メディア: 単行本（ソフトカバー）
- 購入: 8人 クリック: 284回
- この商品を含むブログ (97件) を見る
中古だと多少なりと値段が下がっているので求めやすい。
※戦闘機本はだいぶ前に買ったけど数ページ読んでBOOK OFFに売った記憶がある。
戦闘機本には、ErlangのVMであるBEAMに関する説明はない。あくまでErlang言語としても解説書といった感じだ。
ネット上の情報
その他にネット上の情報も参考にさせて頂きました。
こちらの記事のリンクを流し読みしてみる。
比較的短時間で読めたのはこちらの記事。
但し、ErlangのR15について述べた文章とのことなので、恐らく現在のR20.1と食い違う部分はあるんだろう。
読んでわかったこと
ErlangのVMはスタックマシンではない。レジスタマシンだ。
スタックマシンではなくてレジスタマシンということは分かったがレジスタマシンのメリットはよく分かっていない。
そもそもVMである以上レジスタだのスタックだのと言ったところでどちらもメモリ上で実現されていることに変わりはないはずだ。
Erlangではレジスタの一部をCPUの物理的なレジスタに割り当てているとのこと。(文脈からすると386系だとEAXレジスタのことっぽい)
BIF(Built In Functions)
Erlangには強力な組込関数群が提供されているらしい。
ソースを見ていてもBIFのプレフィックスで始まるファイルとか関数がある。
これらは組込関数に関係したものだということだろう。
スケジューラの動作について
分かったことよりよく分からない事の方が多い。
少なくとも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に関するかなり膨大な知識が必要になるんじゃないだろうか。
その他(英語訳について)
訳がわからない単語とかちょくちょく出てくる。
- yield
コンピュータサイエンスの文脈では「生成する」の意味で使うことが多いみたい。
今まで意味を気にしてなかったけど、Rubyの yieldはブロックの処理を実行する機能なのでこれは、恐らく「明け渡す」「譲る」の意味なんだろう。
yielding だと「降伏する」という意味になるらしい。
日本語でもそうだけど、こういう１つの単語にいろんな意味を割り当てるのはやはりよくない気がする。
同じような例で、マイコンのマルチファンクションGPIOもバグがでやすい。何処がよくないのか調べるのも時間がかかる。
１単語＝１目的
がいい。
- forgoes
「なしで済ませる」「見合わせる」という意味。
forgoes throughput for lower latency.
は
低レイテンシによるスループットの低下
と訳すようだ。(Google翻訳による)
これもすぐにはピンとこなかった。
- From time to time
随時。
- a quite intricate process
かなり複雑なプロセス。
英語の翻訳は根性で乗り切るしかないな。
BEAM BOOKは丁寧に解説が書かれている印象があるが、ソースを軽く見たけど解説とソースとの対応関係が分からない。
もう少し、PDFの方を読んでからソースを見た方がいいかもしれない。
