DEV Community: N. Shimizu

WebAssembly でも feature detection したい

N. Shimizu — Mon, 30 Mar 2020 01:18:49 +0000

TL;DR;

wasm-feature-detect を使えば、ブラウザのサポートしている機能を確認できます。

import { simd } from "https://unpkg.com/wasm-feature-detect?module";

simd().then(simdSupported => {
  if (simdSupported) {
    /* SIMD support */
  } else {
    /* No SIMD support */
  }
});

WebAssembly でも feature detection 必要？

必要です。2019年末の時点で、モダンブラウザと呼ばれるブラウザは WebAssembly の Minimal Viable Product(MVP) と呼ばれる機能をサポートしています。c.f. caniuse.com

MVPがサポートされてのち、仕様の拡充は進められています。どのような仕様が提案されているかは、（2019年夏の情報ではありますが）Kabuku さんの「夏休みだョ！WebAssembly Proposal 全員集合！！」で概観できます。

SIMD 命令
Thread
多値関数
メモリの一括アクセス、変更

これらはいくつかのランタイムでサポートされています。別の言い方をすれば、サポートされていないランタイムも存在します。例えば Thread は Chromium ではデフォルトで利用できるのに対し、他のエンジンでは実装中です。

Web ではいつものことですが、WebAssembly を利用する場合、開発者は次のどちらかを迫られます：

サポートするブラウザのセットを定め、その上で利用できる機能のみを使う
Progressive enhancement を行う / advanced な機能が使える環境では、その機能を利用する

前者を考えると、MVP のみを利用するというのが良さそうです。

ここでは後者について考えます。Progressive enhancement を行うには、そのブラウザでどの機能が使えるかどうかを調査する必要があります。

これは JS ではおなじみの作業です。例えば Native Filesystem API をサポートしているかどうかは、次のように API で代表的な関数が存在するかどうかを調査することでわかります：

if(window.chooseFileSystemEntries != null){
// サポートしてる
}else{
// サポートしてない
}

WebAssembly ではこの手法をそのまま使えません。少し変化が必要です。

確認するのは operator の有無

JS の場合確認していたのは関数の有無でした。これは API は NavigatorオブジェクトやDocumentオブジェクトなどの属性値や、global の名前空間のオブジェクトとして露出するからでした。

WebAssembly の機能は、そのように JS の空間には露出していません。サポートの有無を確認するには、wasm ファイルをインスタンス化し、実行する必要があります。

もしブラウザがある機能をサポートしているならば、その機能に定義されているオペレーターがサポートされています。またサポートされていないオペレーターを評価すると、トラップが発生します。このトラップは JavaScript では例外としてハンドルできます。つまり次のようなコードで、サポートを有無を判定できます。

function isXXXSupported(){
  try{
    // WASM モジュールのインスタンス化と実行
    return true;
  }catch(e){
    // 例外がきたらfalseを返す
    return false;
  }
}

例えば SIMD の場合、次のようなモジュールを呼び出すことで、サポートの有無を調べられます。i16.x8.splat は数値から v128 を作る命令です。

(module 
  (func
    i32.const 0
    i16x8.splat
    drop
  )
)

手で WASM を書くのは面倒

面倒ですね。そこでライブラリを利用しましょう。wasm-feature-detect というライブラリは、上記の方式を（より賢く）実装しています。これを使うことで、次の機能の有無を調査できます：

BigInt
バルクメモリアクセス
例外
多値関数
ミュータブルなグローバル変数
レファレンス型
floatからintへのトラップなしでの変換
符号の変換
SIMD（固定長）
末尾呼び出し
スレッド

このライブラリは ES モジュールとして実装されています。またそれぞれの機能の調査は、対応する関数を呼び出すことで行えます。例えば SIMD サポートの有無は次のように simd 関数を呼び出すことで確認できます。

import { simd } from "https://unpkg.com/wasm-feature-detect?module";

simd().then(simdSupported => {
  if(simdSupported){
   //  SIMD がサポートされている
  }else{
   // サポートされていない
  }
});

npm にも登録されています：

% npm install -g wasm-feature-detect

まとめ：feature detection してどうするの？

そのブラウザで利用できる機能がわかります。それに合わせて、機能を利用するビルドをロードするか、それとも MVP だけを利用したビルドをロードするかを決めます。

フォールバックを持っておくことは、progressive enhancement の文脈では大切なので、その方式で WASM を利用するなら、MVPで作ったものと、全部いるの 2 つのビルドは作っておかないといけないということになるでしょう。

Emscripten で C/C++ から JS の関数を呼ぶには

N. Shimizu — Mon, 30 Mar 2020 01:17:37 +0000

TL;DR;

コード中に JavaScript を埋め込む
外部関数として定義して、実装を　WASM 出力時に埋め込む

このどちらかで、JavaScriptのユーザ定義関数を呼べます。DOM APIのいくつかは、html5.h に定義されている関数を通じて呼ぶことができます。

WebAssembly から JS の関数を呼ぶには（一般的な話）

WebAssembly はソフトウェアモジュールを定義します。ES モジュールと同様に、関数をエキスポートするだけではなく、他のモジュールで定義された関数をインポートできます。

インポートされる関数に関する情報は、wasm ファイルに書かれています。この情報は import セクションに「どういう引数 / 返り値の関数が」「どういう名前で与えられるか」という形で書かれています。

(import "console" "log" (func $log (param i32)))

この例では、i32の値を1つだけ引数としてとり、返り値は返さない関数が、"console"モジュール内の"log"という属性で与えられる、ことが記述されています。また、このインポートされた関数が$logとして、モジュール内で参照されるということもわかります。引数情報を除くと、次の ES モジュールのインポートと同じような振る舞いをします。

import {log as $log} from "console";

インポートされる関数の実装は、WASM モジュールのインスタンス化時に与えられます。

const mod = await WebAssembly.instantiateStreaming(stream, {
  console: {
    log: function(ptr){ ... }
  }
});

このように、WebAssembly.instantiate / WebAssembly.instantiateStreaming の第２引数でインポートされる関数の実装を与えます。

以上をまとめると、WebAssembly から JS の関数を呼ぶには次の2点がポイントになります：

どのように WebAssembly の方に関数のシグネチャを書くか
どのようにインスタンス時に実装を与えるか

この2点はコンパイラ/ツールによって抽象化されていることが多いのですが、それでも元のコードの変更と、JS の実装を行わなければなりません。この視点からコンパイラ/ツールを見ると理解が早まるかと思います。

Emscripten で利用できる手段

Emscripten では次の2つのアナロジーを使って抽象化しています：

インラインアセンブラ
外部関数の定義と、プログラムのリンク

どちらも C/C++ のプログラマには馴染みある概念かと思います。

`EM_JS`：インライン JavaScript

インラインアセンブラに相当するものが、ES_JS です。これを利用すると C/C++ の中に JavaScriptt の関数定義を埋め込むことができます。

次の例では、コンソールに"pass"というログを出す関数 pass を定義して、main 関数から呼び出しています：

#include <emscripten.h>

EM_JS(void, pass, (), {
  console.log("pass");
});

int main(int argc, char **argv){
  // 略
  pass();
  // 略
  return 0;
}

EM_JS は emscripten.h に定義されているマクロです。4つのパラメータがあります：

返り値の型
関数名
引数リスト
関数本体

関数本体は JavaScript で定義します。

もし1ショットで JavaScript のコードを実行するなら、EM_ASM というマクロの方が適切です。次のように使えます：

int main(int argc, char **argv){
  // 略
 EM_ASM({
   console.log("pass");
 });
  // 略
 return 0;
}

外部関数の実装を JavaScript で与える

外部関数の実装を JavaScript で与えることもできます。例えば、先ほどの pass 関数を、次のように宣言したとします：

extern void pass();

int main(int argc, char **argv){
  // 略
  pass();
  // 略
  return 0;
}

別のファイルでこの関数を実装して、リンク時に解決するのはよく行われます。同じことを JavaScript で行おうというのが、この方式です。

実装するファイルは次のようになっています。関数を定義した後に、mergeIntoを呼び出し実装と、シグネチャとの対応づけます：

function pass(){
  console.log("pass");
}

mergeInto(LibraryManager.library, {
  pass
});

mergetInto は第1引数のオブジェクトの属性に、第2引数の属性をマージする関数です。LibraryManager.library には C/C++ からリンクされる JS コードが保持されます。

このファイルを　--js-library オプションの値に指定して emcc コマンドを実行することで、WASM ファイルと「リンク」できます。

この方式はマングリングされているとうまく動きません。C++ の場合は、次のようにマングリング対象から外しておく必要があります：

extern C{

  extern void pass();

}

まとめ：どっちがいいか？

どちらを取るかは、コード量によると思っています。比較的短いコードなら EM_JS を、そうでなければリンクする方が開発しやすいでしょう。

JavaScript として実装し、テストも JS の技術で完結できるので、私はリンクする方が好みです。

Asyncify を使ってみた

N. Shimizu — Mon, 30 Mar 2020 01:16:23 +0000

TL;DR;

Aysncify を使うことで、同期的な C/C++ 関数を、非同期なものにできます
-s ASYNCIFY=1 をコンパイラオプションに指定した上で、 -s 'ASYNCIFY_IMPORTS=["関数1", "関数2", …]'のように非同期化する関数名を列挙してコンパイルします
出力される JS ファイルのサイズと、WASM ファイルサイズが増えます

Aysncify とは

Asyncifyとは、Emscripten の提供する機能の 1 つです。これを使うと次のことが可能になります。まさにマジック。

同期的なC/C++のコードを、非同期化します
非同期なJS APIの結果を、C/C++ 側では（擬似的な）同期的に受け取ることができます

何ができるのかを、試した結果をまとめました。まずは無限ループがあるコードを例にみてゆきましょう。

無限ループのあるコードが、メインスレッドで動く

次のようなプログラムがあるとします。タイマーの状態を確認して、その値が true になったら無限ループから抜けて終了する、というものです。

#include <stdio.h>
#include <unistd.h>

extern "C" void start_timer();
extern "C" bool check_timer();

int main(int argc, char** argv){
  start_timer(); // タイマーの起動
  while(true){
    if(check_timer()){ // タイマーの値を確認
      printtf("Timer happened.\n");
      break;
    }
    printf("Sleeping\n");
    usleep(100000); // 100ms スリープする
  }
  return 0;
}

典型的なビジーループのコードで、C/C++ では珍しくないと思います。ただ JavaScript 開発者にとっては驚きだと思います。同様のコードを JavaScript でも記述できますがスレッドを占有してしまうので、ブラウザの UI もブロックしてしまいます。そのため、次のように setInterval や requestAnimationFrame を使って、メッセージループから起動されるように記述するのが常でした。

import {start_timer, check_timer} from "some-module";

function main(){
  function update(){
    if(check_timer()){
      console.log("Timer happened");
    }else{
      console.log("Sleeping");
      requestAnimationFrame(update);
    }
  }
  start_timer();
  update();  
}

Ayncifyは上記のような C/C++ のコードを、大きな書き換えなしに非同期化します。

Asyncify を使った非同期化

先ほど例に使ったコードを Asyncify を使って非同期化していきます。

#include <stdio.h>
#include <unistd.h>

extern "C" void start_timer();
extern "C" bool check_timer();

int main(int argc, char** argv){
  start_timer(); // タイマーの起動
  while(true){
    if(check_timer()){ // タイマーの値を確認
      printtf("Timer happened.\n");
      break;
    }
    printf("Sleeping\n");
    usleep(100000); // 100ms スリープする
  }
  return 0;
}

まずはコードを次のように書き換えます。次の 3 点が差分です：

unistd.h の代わりに emscripten.h をインクルード
EM_JS マクロを使って　start_timer と check_timer の実装を定義
usleep を emscripten_sleep で置き換え

EM_JS については、こちらのエントリーを参照してください。また Module オブジェクトについては、公式ドキュメントに説明があります。

#include <stdio.h>
#include <emscripten.h>

EM_JS(void, start_timer, (), {
  Module.timer = false;
  setTimeout(function(){
    Module.timer = true;
  }, 500);
})

EM_JS(bool, check_timer, (), {
  return Module.timer;
})

int main(int argc, char** argv){
  start_timer(); // タイマーの起動
  while(true){
    if(check_timer()){ // タイマーの値を確認
      printtf("Timer happened.\n");
      break;
    }
    printf("Sleeping\n");
    emscripten_sleep(100); // 100ms スリープする
  }
  return 0;
}

このコードを次のようにコンパイルします。ポイントは -s ASYNCIFY=1 をオプションに加えることです。

% emcc -s ASYNCIFY=1 -o timer.js timer.c

出力された　JS ファイルを Node で実行すると、次のようになります：

% node timer.js
Sleeping
Sleeping
Sleeping
Sleeping
Timer happened.

もちろんブラウザーでも動きます。次のような HTML ファイルを用意して、テスト用の Web サーバーに配置して、アクセスすると、コンソールに上記のように出力されると思います。

この時注目したいのは、ブラウザの UI が固まっていない点です。例えば新しいタブを開こうと思えば、ひらけます。これはメインスレッドが JS / WASM の実行で占有されていないことを示しています。

<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Timer with Asyncify</title>
    <script defer src="timer.js"></script>
  </head>
 <body></body>
</html>

`emscripten_sleep` の自作

先ほどのコードがメインスレッドを占有しないのは、emscripten_sleep が Asyncify に対応していて、sleep 中にメインスレッドを明け渡していました。関数呼び出し時にメインスレッドを明け渡すことと、関数の処理が終了した際にCのコードの実行部分に戻ることが Asyncify の特徴のようです。

これを利用して、自分で emscripten_sleep を作ってみます。まず準備として、先ほどのコードで実装した start_timer と check_timer を JS ファイルに切り出します。

function start_timer(){
  Module.timer = false;
  setTimeout(function(){
    Module.timer = true;
  }, 500);
}

function check_timer(){
  return Module.timer;
}

切り出した JS ファイルは、lib.js としておきます。この lib.js をリンクするように、元のコードも変更します。

一緒に自作版 emscripten_sleep のシグネチャも追加し、それを呼び出すように変更します。

#include <stdio.h>

extern "C" void start_timer();
extern "C" bool check_timer();
extern "C" void mysleep(int);

int main(int argc, char** argv){
  start_timer(); // タイマーの起動
  while(true){
    if(check_timer()){ // タイマーの値を確認
      printtf("Timer happened.\n");
      break;
    }
    printf("Sleeping\n");
    mysleep(100); // 100ms スリープする
  }
  return 0;
}

lib.js に mysleep を実装します。Asyncify.handleSleep を呼び出すのがポイントです。この中に非同期処理を記述します。JSのPromiseと似た記法です。似ているといえば、非同期処理の最後に wakeUp を呼び出す点も、resolve/rejectを呼ぶのと似ています。wakeUpを呼び出すと、処理は呼び出し元へ戻ります。

function mysleep(interval){
  Asyncify.handleSleep(function(wakeUp) {
    setTimeout(function(){
      wakeUp();
    }, interval);
  });
}

lib.js をリンクできるように、コンパイルオプションに --js-library を追加します。また ASYNCIFY_IMPORTS というリストに、Asyncify で非同期化する関数を列挙します（ドキュメント）：

% emcc -s ASYNCIFY=1 -s 'ASYNCIFY_IMPORTS=["mysleep"]' --js-library lib.js -o timer.js timer.cpp

なお ASYNCIFY_IMPORTS を指定しない場合でも、コンパイルエラーは起きません。ただ実行した際にエラーが起きます。戻り先で unreachable が実行されてしまうためです。

簡易的なイベントループを自作する

ここまでで自分で定義した関数を、非同期化できるようになりました。これを踏まえて、次のようなイベントループを持つプログラムを Asyncify を使ってメインスレッドで動くようにしていきます。

#include <stdio.h>

extern "C" int get_key();
extern "C" void update(int keycode);

int main(int argc, char **argv) {
  while (true) {
    int key = -1;
    key = get_key();
    if (key >= 0) {
      update(key);
    }
    if (key == 27) {
      printf("breaks from the main loop");
      break;
    }
  }
  return 0;
}

これはキーコードを取得し、取得したキーコードを引数に update 関数を呼ぶというプログラムです。些末なことですが、ESC キーを押すと、ループから抜け、プログラムが終了します。このプログラムは main.cpp に記述されていることとします。

get_key がキーコードを取得する関数です。これを非同期処理にすることで、メインスレッドがブロックされるのを防ぎます。先の例にならって、lib.js に実装します。

function get_key() {
 Asyncify.handleSleep(function(wakeup) {
    const handler = function() {
      const key = keys.shift();
      const code = key == null ? -1 : key;
      wakeup(code);
    };
    requestAnimationFrame(handler);
  });
}

このように適当に実装しました。キーイベント自体は、別の場所で取得しておきキーイベントキューに入れておきます。keys が、そのイベントキューになります。実体は別のJSファイル（pre.js としておきます）に定義されています：

const keys = [];
function setKeyEventHandler() {
  document.body.addEventListener('keydown', e => {
    keys.push(e.keyCode);
  });
}
setKeyEventHandler();

あとは update 関数を適切に実装します。実装は lib.js 内に記述します。

これを次のようにコンパイルすることで、メインスレッドを占有しないイベントループが実現できます。

% emcc --pre-js pre.js --js-library lib.js -s ASYNCIFY=1 -s 'ASYNCIFY_IMPORTS=["get_key"]' -o eventloop.js main.cpp

JS / WASM のサイズは増加します

便利な Asyncify ですが、ドキュメントによるとトレードオフは存在します。それはコードサイズの増大と、実行時のオーバーヘッドです。

詳しく内部はみていませんが、Asyncify は次のことを行うようです。これの実装を行うための処理が JS と WASM に追加されるためコードサイズが増え、また処理時間も増大するということのようです。

C/C++ のコールスタックの保存と復元
ASYNCIFY_IMPORTS に列挙された関数の分割

これを確かめてみようと思いました。非同期化しなくても動くプログラム、ということでフィボナッチ数を計算する関数を Asyncify を使って非同期化したビルドと、しなかったビルドを作り、比較しました。

フィボナッチ数の計算

次のようなナイーブな実装を行いました：

function doFib(n) {
  if (n < 3) {
    return 1;
  }
  return doFib(n - 1) + doFib(n - 2);
}

Asyncify に対応した関数を次のように定義し、これを C++ のコードから呼んで実行時間を計測しました。

function calc(n) {
  return Asyncify.handleSleep(function(wakeup) {
    const result = doFib(n);
    wakeup(result);
  });
}

コントロール群のデータは、次のように Asyncify を使わないものを作り、同様に C++ のコードから呼び出し計測しました。

function calc(n) {

  return doFib(n);

}

速度の比較

実験計画

n の値を 20, 25, 30, 35 と 4 段階に変化させ、それぞれの n に対し、フィボナッチ数を計算します
計算を 100 回行い、その実行時間を nano sec. 単位で計測します
2 を、それぞれの n に対して 5 回ずつ実行し、得られた平均値の平均を算出します
3 を比較します

回数は適当に決めました。なんとなくの傾向が出ればいいかな、くらいのつもりでした。

結果

群	n = 20	n = 25	n = 30	n = 35
Asyncifyなし	43193.64	421036.328	4794282.62	53285812.46
Asyncifyあり	45401.08	464750.99	4933509.36	56418746.00

5% から 10% ほど、Asyncify ありの方が遅くなっています（上記の表の単位は nano sec.で、小数点３桁以下は切り捨てています）。

検定などしていませんし、実験計画も自信がないので意味ある結果とはいえませんし、requestAnimationFrame で次のtickを待っている分遅くなっているのかな？とも思えます。

コードサイズの比較

単純に ls で比較しました。どちらも -O3 で最適化しています。

群	JS ファイル	WASM ファイル
Asyncifyなし	16K	9.2K
Asyncifyあり	42K	22K

顕著にファイルサイズが増大していることがわかります。

まとめと雑感

良い点：C/C++ としてシンプルなコードを、そのまま Web に持っていける可能性が高まる
悪い点：ファイルサイズが増える

Asyncify を使えば C/C++ でよくあるメッセージループも、 C/C++ 側の変更がほとどんどない形でブラウザー上で動作させられる可能性が出てきました。

これまでも vim.wasm のように Worker と SharedArrayBuffer を使って実現するという方法もありました。ツールが非同期処理を仮想的に同期化してくれるため開発者の負荷、特にメンタル面の負荷を減らせるように感じています。

コードがシンプルになる一方で、ファイルサイズは増大します。モバイル Web では影響を慎重に計らなければならないでしょう。

パフォーマンスオーバーヘッドも、もしかしたらあるかもしれません。私の実験では、5% 程度のオーバーヘッドがありましたが、適用例が適切だったかは自信がありません。またメインスレッドが占有され、UI が処理を受け付けないという状態を避けられることに比べれば、多少のパフォーマンスオーバーヘッドは許容できる場合もおおいのでは？という気もしています。

レファンレンス

WASM ファイルのサイズを小さくするには（Rust編）

N. Shimizu — Mon, 30 Mar 2020 01:14:09 +0000

TL;DR;

wasm-packを使いましょう。

はじめに

こちらの記事で、Rustでwasm32のバイナリを出力できるようになりました。こちらの記事で作成されたhello-world.wasmのサイズは875KBでした。これを小さくしていくのが、この記事の目的です。

ここに書いたことの大半は、wasm-packが面倒を見てくれます。手でいろいろやりたい、という人向けの記事となっています。

releaseビルド

Rustのビルドには、debugビルドとreleaseビルドがあります。

debugは名前の通り、デバッグ用のビルドです。最適化はあまりされておらず、デバッグ用の情報も追加されています。cargoコマンドでビルドした際のデフォルトは、debugビルドです。

一方releaseビルドは、最適化がなされ、デバッグ用の情報も追加されていません（通常は）。--release オプションを指定してビルドすると、releaseビルドされたバイナリを作成できます。

% ls target/wasm32-unknown-unknown/release
build           examples        hello-world.wasm    native
deps            hello-world.d       incremental

で、releaseビルドをでは、どれくらいサイズが小さくなってるのかというと、実はあんまり小さくなっていません。

ビルド	サイズ
debug	875K
release	866K

より小さくするために、最適化オプションを変更してみることにします。

lto オプションと最適化レベルの指定

Cargo.tomlには最適化レベルを指定できます。何が書けるかはThe Rust Programming Language BookのThe manifest formatの節に説明があります。

このファイルに次の3行を追加します。

[profile.release]
lto = true
opt-level = "z"

ltoオプションにtrueを指定することで、ライブラリのリンク時も最適化を行います。またopt-levelは最適化レベルを表します。zは、より積極的にバイナリサイズを小さくするように最適化を行います。

結果は次のようになりました。

ビルド	サイズ
debug	875K
release	866K
lto + -Oz	273K

だいぶ減りました。もう少し減らすために、何が原因かを調査します。

コードサイズプロファイラ

コードサイズを増やしている原因を調査するために、コードサイズプロファイラと呼ばれるツールを利用することにします。今回はtwiggyと呼ばれるツールを利用します。

tiwggyは、次のようにcargoコマンドを使ってインストールできます。

% cargo install twiggy

twiggyはいくつかのサブコマンドがありますが、topを使うと次のように、どの項目が、どれだけのサイズなのかをランキングで表示できます。

Shallow Bytes	Shallow %	Item
82059	29.37%	`custom section '.debug_info'`
76288	27.30%	`custom section '.debug_line'`
46774	16.74%	`custom section '.debug_str'`
25201	9.02%	`custom section '.debug_ranges'`
7738	2.77%	"function names" subsection
7595	2.72%	`data[0]`
3315	1.19%	`dlmalloc::dlmalloc::Dlmalloc::malloc::h8a37a103d2401d9d`
1656	0.59%	`main`
1514	0.54%	`std::io::Write::write_all::hfd4c5b414ccb1671`
1399	0.50%	`<str as core::fmt::Debug>::fmt::hda75deb2d8ed9e81`
23210	8.31%	`... and 251 more.`
276749	99.04%	Σ [261 Total Rows]

なおこの結果は、次のコマンドは実行して得ました。topはサイズのランキングを出すサブコマンドす。-nオプションを加えることで、何位までを出力するかを決められます。

% twiggy top -n 10 target/wasm32-unknown-unknown/release/hello-world.wasm

デバッグ情報の削除

上記の結果を見ると、デバッグ情報が大きなサイズを取っていることがわかりました。これを削除します。削除には、wasm-snipというツールを利用しました。

wasm-snipのインストールと、デバッグ情報の削除

Cargoコマンドでインストールできます。

% cargo install wasm-snip

不要なコードの削除は、次のように行います。-oオプションには、不要な情報が削除されたwasmファイルのパスを指定します。

% wasm-snip -o hello-world-snipped.wasm target/wasm32-unkown-unknown/release/hello-world.wasm

結果は、次のようになりました。もとの20分の1程度には小さくなりました。

ビルド	サイズ
debug	875K
release	866K
lto + -Oz	273K
wasm-snip	45K

どこにデバッグ情報があるのか？

WebAssebmlyにはCustom Sectionあります。このセクションは、モジュールの振る舞いには影響は与えないが、処理系にとって有用な情報を書く場所として定義されています。

デバッグに必要な情報も、振る舞いには影響を与えないが処理系にとって有用な情報なので、ここに書かれます。

まとめ

Cargo.tomlでLTOを有効にすること
コンパイラの最適化オプションを変えて、zにすること
wasm-snipをつかって、不要なコードを削除すること

以上が、この記事のまとめです。

はじめにの節にも書きましたが、ここに書かれていることの大半はwasm-packが面倒を見てくれます。ただ、LTSや最適化オプションあたりは自分で設定することもできます。

またこれ以上のバイナリサイズの削減も、きっとできるとは思いますが、それは別の記事としようと思っています。

DEV Community: N. Shimizu

WebAssembly でも feature detection したい

TL;DR;

WebAssembly でも feature detection 必要？

確認するのは operator の有無

手で WASM を書くのは面倒

まとめ：feature detection してどうするの？

Emscripten で C/C++ から JS の関数を呼ぶには

TL;DR;

WebAssembly から JS の関数を呼ぶには（一般的な話）

Emscripten で利用できる手段

EM_JS：インライン JavaScript

外部関数の実装を JavaScript で与える

まとめ：どっちがいいか？

Asyncify を使ってみた

TL;DR;

Aysncify とは

無限ループのあるコードが、メインスレッドで動く

Asyncify を使った非同期化

emscripten_sleep の自作

簡易的なイベントループを自作する

JS / WASM のサイズは増加します

フィボナッチ数の計算

速度の比較

実験計画

結果

コードサイズの比較

まとめと雑感

レファンレンス

WASM ファイルのサイズを小さくするには（Rust編）

TL;DR;

はじめに

releaseビルド

lto オプションと最適化レベルの指定

コードサイズプロファイラ

デバッグ情報の削除

wasm-snipのインストールと、デバッグ情報の削除

どこにデバッグ情報があるのか？

まとめ

`EM_JS`：インライン JavaScript

`emscripten_sleep` の自作