Mozilla HacksのA cartoon intro to WebAssemblyを読みました。Lin Clark氏によるWebAssembly解説シリーズの入口にあたる記事で、「WebAssemblyは速い」と言われる理由を、JavaScriptの性能史から順に説明していく導入編です。
この記事の良いところは、WebAssemblyをいきなり低レベル仕様として説明しない点です。まずJavaScriptが1995年に生まれ、2008年ごろの“performance wars”でJITにより大きく高速化し、Node.jsのような新しい用途へ広がった流れを振り返ります。そのうえで、WebAssemblyがもう一つの性能上の転換点になり得る、という見立てを置いています。
記事の要点
- WebAssemblyは、JavaScript以外の言語で書かれたコードをブラウザで実行するための仕組みです。
- 記事は、WebAssemblyとJavaScriptを二者択一として扱っていません。実際には、同じアプリケーション内で両方を使う前提で説明されています。
- JavaScriptは、JITコンパイラの導入によって大きく高速化し、利用範囲を広げました。
- WebAssemblyは、その次の性能上の転換点になる可能性があるものとして紹介されています。
- 記事単体で完結するというより、JIT、assembly、WebAssembly modules、WebAssemblyの速さ、MVPと将来機能へ進むシリーズの目次になっています。
参照リンクから見えたこと
記事中のリンク先も確認しました。JITコンパイラの解説では、JavaScriptエンジンが実行中にコードを観察し、warm/hotな部分を最適化していく流れが説明されています。WebAssemblyの速さを理解するには、まずJITがどのようにJavaScriptを速くしてきたかを見る必要があります。
assemblyの解説では、コンパイラが高水準言語を中間表現へ落とし、さらにターゲットCPU向けの機械語へ変換する流れが示されます。続くWebAssembly moduleの記事では、WebAssemblyが物理CPUではなく“概念機械”向けの低レベル形式として位置づけられます。
さらに、WebAssemblyの速さの記事とMVPと将来機能の記事までつながることで、WebAssemblyは単なる高速化テクニックではなく、標準化された実行形式として段階的に作られていることが見えてきます。
気づき
今回の気づきは、この導入記事がWebAssemblyを“JavaScriptキラー”として煽っていないことです。むしろ、JavaScriptの柔軟さとWebAssemblyの低レベル性を同じアプリ内で使い分ける前提にしています。WebAssemblyを正しく理解するには、置き換えではなく、役割分担の技術として見るほうが実態に近いと感じました。
コメントを残す