C++とWebAssembly

WebAssembly (Wasm) は、高性能なシステム言語と最新のウェブブラウザのユニバーサルランタイムとの間の重要な架け橋として機能し、ウェブ開発の状況を根本的に変えました。JavaScriptがウェブの紛れもない共通語である一方で、3Dレンダリング、複雑な物理シミュレーション、暗号化、リアルタイムのオーディオ/ビデオ処理といった分野では、動的でガベージコレクションされる言語のレイテンシと実行時間では単純に不十分です。そこで登場するのがWebAssemblyです。これは、ほぼネイティブな速度で実行されるように設計された、効率的で低レベルのバイトコード形式です。そして、Wasmを最大限に活用するとなると、C++がしばしば最適な選択肢となります。

この詳細な解説では、WebAssemblyのアーキテクチャ、Emscriptenを使用したコンパイルパイプライン、メモリ管理の複雑さ、C++とJavaScript間の相互運用性について探ります。

Audio Briefing• Voice: Google Cloud Journey-F

0:00 / 0:00

WebAssemblyの実行モデル

WebAssemblyは、その核となる部分でスタックベースの仮想マシンです。ブラウザが迅速に解析し、マシンコードにコンパイルできるポータブルなバイナリコード形式を定義しています。Wasmモジュールはサンドボックス化されており、ホストマシンのファイルシステムやネットワークとは分離されたメモリセーフな環境で実行され、I/OやDOM操作にはインポートされた関数のみに依存します。

C++をWasmにコンパイルすると、結果として得られる.wasmファイルには、線形メモリレイアウト、関数ポインタのテーブル（C++の仮想メソッドディスパッチに不可欠）、およびホスト環境（JavaScript）のAPIサーフェスとして機能するエクスポートされた関数のセットが含まれます。

このモデルの美しさは、その予測可能性にあります。Just-In-Time (JIT) コンパイルとヒューリスティックベースの最適化に大きく依存するJavaScriptエンジンとは異なり、Wasmの実行は決定論的です。ブラウザのWasmコンパイラ（V8のLiftoffやTurboFanなど）は、Wasmバイトコードを最適化されたネイティブマシンコードに一度のパスで変換でき、多くの場合、ファイルがダウンロードを完了する前に行われます。

Emscriptenの登場：コンパイルパイプライン

C++をWebAssemblyに変換するための業界標準ツールチェーンはEmscriptenです。LLVMコンパイラインフラストラクチャ上に構築されたEmscriptenは、単なるコンパイラ以上のものです。それはウェブのためのPOSIX互換エミュレーションレイヤー全体です。

emcc（Emscripten C++コンパイラ）を呼び出すと、パイプラインはいくつかの段階を経ます。

フロントエンドコンパイル (Clang): C++ソースコードが解析され、LLVM中間表現 (IR) に変換されます。この段階では、テンプレート、クラス、例外を含むすべてのC++固有の機能が処理されます。
最適化 (Opt): LLVMは、ループアンローリング、デッドコード削除、関数インライン化など、IRに一連の最適化を適用します。これは、最終的なWasmペイロードのサイズを最小限に抑えるために重要です。
バックエンドコード生成: 最適化されたLLVM IRはWebAssemblyバイトコードに変換されます。
リンク (wasm-ld): Emscriptenのリンカは、コンパイルされたオブジェクトファイルを標準ライブラリ（libc、libc++）と、EmscriptenによってエミュレートされたシステムAPI（WebGLに変換されたOpenGL、Web WorkersにマッピングされたPOSIXスレッドなど）と結合します。

最小限の例

マンデルブロ集合の計算のような、非常にCPU負荷の高いアルゴリズムを考えてみましょう。C++では、SIMD命令（WebAssemblyが現在サポートしています！）を使用してこれを大幅に最適化できます。

cpp

#include <emscripten/bind.h>
#include <vector>
#include <cmath>

using namespace emscripten;

class FractalEngine {
public:
    FractalEngine(int width, int height) : width(width), height(height) {
        buffer.resize(width * height * 4);
    }

    val getBuffer() const {
        return val(typed_memory_view(buffer.size(), buffer.data()));
    }

    void compute() {
        // High-performance nested loop utilizing CPU caches optimally
        for (int y = 0; y < height; ++y) {
            for (int x = 0; x < width; ++x) {
                // Complex mathematical operations...
                int idx = (y * width + x) * 4;
                buffer[idx] = 255;     // R
                buffer[idx + 1] = 100; // G
                buffer[idx + 2] = 50;  // B
                buffer[idx + 3] = 255; // A
            }
        }
    }

private:
    int width, height;
    std::vector<uint8_t> buffer;
};

EMSCRIPTEN_BINDINGS(fractal_module) {
    class_<FractalEngine>("FractalEngine")
        .constructor<int, int>()
        .function("compute", &FractalEngine::compute)
        .function("getBuffer", &FractalEngine::getBuffer);
}

embindを活用することで、FractalEngineクラスをJavaScriptに直接公開し、境界を越えてシームレスなインスタンス化とメソッド呼び出しを可能にします。

メモリ管理とWasm境界

WebAssemblyでC++を使用する最も複雑な側面の1つはメモリ管理です。Wasmは、連続したサイズ変更可能なArrayBufferを線形メモリスペースとして利用します。すべてのC++ポインタは、このArrayBufferへの単なる整数オフセットです。

境界を越えるコスト

Wasmの実行は非常に高速ですが、WebAssemblyとJavaScriptの間（「トランポリン」）で境界を越えることには、無視できないオーバーヘッドが発生します。C++関数がJS関数を呼び出すたびに、またはその逆の場合、引数をマーシャリングし、実行コンテキストを切り替える必要があります。

高性能アプリケーションの場合、黄金律は境界を越える回数を最小限に抑えることです。個々のオブジェクトを渡したり、小さな関数を頻繁に呼び出したりする代わりに、アプリケーションを設計して大きなデータブロックを渡すようにします。

マンデルブロの例では、ピクセルごとにC++関数を呼び出す代わりに、Wasmで画像バッファ全体を計算し、Uint8Arrayビュー（typed_memory_view）をJavaScriptに渡します。これにより、WebGLまたはCanvas APIは、Wasmメモリからデータをゼロコピーセマンティクスで直接消費でき、高価なシリアル化とデシリアル化を回避できます。

ガベージコレクションされた世界での手動メモリ管理

C++は手動メモリ管理（new/delete、またはスマートポインタ）を必要とします。Emscriptenを介してC++オブジェクトをJavaScriptにエクスポートする場合、JavaScriptのガベージコレクタ (GC) は基になるC++ヒープについて何も知りません。C++インスタンスへの参照を保持するJavaScriptオブジェクトがスコープ外になると、C++メモリはリークします。

これを処理するために、Emscriptenはエクスポートされたオブジェクトに.delete()メソッドを提供します。C++オブジェクトが不要になった場合、開発者はJavaScriptで明示的に.delete()を呼び出す必要があります。あるいは、JavaScriptの新しいFinalizationRegistry APIを使用して、C++オブジェクトのライフサイクルをJSラッパーに結び付けることもできますが、これはGCシステムに典型的な非決定的な破棄を導入します。

Web WorkersとSharedArrayBufferによるマルチスレッド

現代のC++開発は、CPU利用率を最大化するために並行処理に大きく依存しています。歴史的に、ウェブはシングルスレッドでした。しかし、Web WorkersとSharedArrayBufferの導入により、WebAssemblyは真のハードウェアスレッドを利用できるようになりました。

Emscriptenは、POSIXスレッド（pthreads）をWeb Workersに直接マッピングすることでこれを簡素化します。-s USE_PTHREADS=1でコンパイルすると、EmscriptenはWeb Workersのプールを自動的にプロビジョニングします。std::mutexやstd::condition_variableなどのC++同期プリミティブは、SharedArrayBuffer上のアトミック操作（Atomics.waitとAtomics.wake）を使用して実装されます。

この機能は、ウェブアプリケーションに前例のないパフォーマンスをもたらし、複雑なシミュレーション、物理エンジン（HavokやBulletなど）、並列データ処理をブラウザ内で直接、複数のコアでほぼネイティブな速度で実行できるようにします。

未来：WASIとその先

WebAssemblyの可能性はブラウザをはるかに超えています。WebAssembly System Interface (WASI) は、Wasmモジュールがホストオペレーティングシステムとどのように相互作用するかを標準化し、ファイルI/O、ネットワーキング、時間のための安全で機能ベースのAPIを提供します。

WASIを使用すると、C++アプリケーションを単一の.wasmバイナリにコンパイルし、WasmtimeやWasmerのようなランタイムを使用して、ウェブブラウザとは完全に独立して、サーバー、エッジノード、IoTデバイスなど、さまざまなプラットフォームで実行できます。これにより、「一度書けばどこでも実行できる」という約束が、セキュリティ、サンドボックス化、ほぼネイティブなパフォーマンスに重点を置いて実現されます。

結論

C++の生の計算能力ときめ細かなメモリ制御を、WebAssemblyの遍在性とセキュリティと組み合わせることは、ソフトウェアエンジニアリングにおけるパラダイムシフトを意味します。基盤となるアーキテクチャを理解し、Emscriptenを効果的に活用し、メモリ境界を最適化することで、開発者は応答性とスループットの点でデスクトップソフトウェアに匹敵するウェブアプリケーションを構築できます。SIMD、スレッド、WASIなどの機能でWebAssemblyエコシステムが成熟し続けるにつれて、C++はこの高性能革命の最前線にあり続けるでしょう。

C++とWebAssembly

WebAssemblyの実行モデル