インタプリタ言語が 実行環境の差異を 吸収する仕組みを あさーく理解する

低レイヤーズさっぽろ #3 -秋- にて発表した資料です。

低レイヤーズさっぽろ #3 -秋-：https://low-layers-sapporo.connpass.com/event/371754/

Transcript

1. インタプリタ言語が 実行環境の差異を 吸収する仕組みを あさーく理解する 低レイヤーズさっぽろ #3 -秋- えび（025cm） 1
2. 自己紹介 - えび - 普段はモバイルを書いている 2
3. 「インタプリタ」のこと、 「インタプリンタ」って ずっと間違えていってた・・・ くるしい。 3
4. 近況：転職した。 - はじめまして、AWS - はじめまして、Java - 久しぶりだね、Kotlin・Swift - ぴよぴよには荷が重い、、、 4
5. 近況： まわりはやさしい。 ぬい活も捗り。 5 前職の机から連れてきた羊🐏
6. 発端 6
8. Rubyって実はOSの環境差異を吸収できる らしい、、、、 8
9. なぜRubyはOSの差異を吸収できるのか… 9
10. 今日話したいこと - RubyとSwiftを題材に、ビルドと実行の違いを通じて、なぜRubyはOSの差異を吸 収できるのか掘ってみる - 正確性 < 雰囲気を掴むイメージで聞いていただけたら、、、、 10
11. ざっくりビルドの流れをおさらい 11
12. Swift - 書いたコード（.swift）を、あらかじめバ イナリに変換 - CPUが直接理解できる命令（＝機械 語）にされる - 実行は速いが、OSごとにビルドが必 要 - CPUに直接渡すからこそ、パフォーマ ンスは高い 12
13. Ruby - 書いたコード（.rb）を、その場で読み ながら実行 - Ruby VM という仮想的なCPUがバイ トコードを解釈 - 実行前にバイナリを作らないから移 植しやすい - その代わり、実行速度はちょっと遅い 13
14. Rubyのほうがなんか工程少なくない・・・？ 14
15. Rubyの過程を見ているとSwiftがコンパイ ル済みのバイナリを作るようなことをその場 でやってて、 CPUを噛ませてなさそうに読めるぞ。。。 15
16. Ruby（インタプリタ）は 逐次翻訳をする 1. .rb を その場で読む 2. 構文解析して AST（抽象構文木）を作る 3. 中間表現（バイトコード） に変換 4. Ruby VM（仮想CPU）がバイトコードを1命令ずつ解釈して実行 - 実行前にバイナリを用意しない - その代わり、Ruby VMが逐次的にCPUの代わりに働く - CPUではなく「Ruby VMという仮想的なCPU」が命令を処理してる 16
17. RubyがOS差異を吸収できる理由 - Rubyは 実行時に VM が処理を肩代わりしてくれるので、 OSごとにバイナリを作り 直す必要がない - VMやGemが持っている抽象化レイヤが厚く、 ファイルパスの違い・ネットワークの 取り扱い・メモリ制約なども、 「Ruby側が吸収してくれる」仕組みになっている。 17
18. Swift（コンパイル）は 先に翻訳する 1. .swift → コンパイルして LLVM中間コードにする 2. OSやCPU向けに最適化されたバイナリを作る（*.app や *.out） 3. 実行時はOSがバイナリをロードしてCPUに渡す 4. CPU命令を実行（Swift runtimeの補助） - バイナリを生成する分、時間はかかるけど実行は早い - OSごとにバイナリは別（だから移植性は劣る） - Swiftのコードは 事前にCPUが直接理解できる形（機械語）に変換される 18
19. RubyがOS差異を吸収しやすい 理由 - ソースコードが中間表現に変換されない - ランタイムが持ってる抽象化レイヤが厚い - RubyはVM上で動く → OS依存の差分をVMやGemが吸収してくれる - OSごとの差異（ファイルパス、ネットワーク、メモリ）を、Ruby本体が抽象化・吸 収してくれる 19
20. Ruby（インタプリタ）は 逐次翻訳をする 1. .rb を その場で読む 2. 構文解析して AST（抽象構文木）を作る 3. 中間表現（YARVバイトコード） に変換 4. Ruby VM（仮想CPU）がそのバイトコードを1命令ずつ解釈して実行 - 実行前にバイナリを用意しない - その代わり、Ruby VMが逐次的にCPUの代わりに働く - CPUではなく「 Ruby VMという仮想的な CPU」が命令を処理してる 20
21. Rubyってもしかしてデバイスドライバとか WiFiチップ系の機能とか、 OSと密なハードウェアと対話する素地弱 かったりする…？ 21
22. 弱いっぽい - Rubyが実行しているのは“Ruby VMの命令”であって、ハードウェアの命令ではな い。 - 低レイヤーにアクセスするにはだいたいCの拡張が必要。 - 直接ハードウェアレジスタや割り込みベクタ、カーネルモジュールのような「生の ハードウェア制御」をそのまま書くことを想定していない 22
23. 最低限の対話しかOSとしない。 （触らぬ神に祟りなし。触れない限り、まろ やかに・友好的に関わることができる） 23
24. （人間関係と一緒だなぁ。。。。。） 24
25. サニタイザーと実行時エラーってどこまで違うねん - Rubyは実行時エラーは検出するけど、Swiftは実行時エラー + サニタイズのエラー も拾える - 実行時エラーは「言語ランタイムや標準ライブラリが用意している安全装置」によっ て検出される -> 言語が責任を持って守る仕様の範囲に限られる - 深いバグ（例えばメモリの越境アクセス、マルチスレッドの競合）は、言語だけでは 保証できないので、サニタイザーの出番になる - そもそもRubyはメモリ空間やスレッド安全性、ポインタ演算には、言語としては踏み 込まない（C拡張を使う） -> そもそもサニタイザーが保証したい領域まで手を伸ばさない感じなのかな。 25
26. サニタイザーってコンパイル言語だからこそ の仕組みなんだ。。。 26
27. まとめ - Rubyは言語のランタイムが担う責務が大きい - CPUに投げている責務が小さいから、環境差異を抑えること ができている - その分、ハードウェアと密な対話が必要な制御に弱い 27