My First WASM Challenge: Building a School of Fish Simulation

Transcript

1. 初めてのWASMで 魚群シミュレーションに挑んだ話 新宿御苑.wasm #2025.10.19
2. • 普段はバックエンド（Java）の開発 • むかし作った魚群シミュレーションを作り直したかった • なんとなく速そうだと思ってWASMとC++に初めて触れた きっかけ
3. 魚群シミュレーション • 個体がリアルタイムに群れとして動 く • 各個体は周囲の動きに反応して 進行方向を調整 • 挙動は Boids アルゴリズムをベー スに独自拡張 • 1万匹以上をリアルタイムで描画
4. 内部処理と性能の壁 • 各魚は周囲の個体を観察して行動を決める。 • つまり毎フレーム、近くの個体を効率的に探す必要がある。 • 個体が数千、数万体いると、そのまま全探索するとO(N²) で 現実的に動かない。 • だから構造（木構造・SoA・スレッド化）や最適化が必須。 • とりあえず動く所までつくったけど…めちゃくちゃ重い。
5. 最初の壁 ― JavaScript↔WASMの境界 • JavaScriptから1匹ずつ 座標、向きを取得していた • 結果 → JavaScript↔WASM間の値の受け渡しがボトルネックに • 計算ではなくデータの受け渡しで遅くなる → C++の性能がまったく活かせない。
6. • JavaScript と C++（WASM）はメモリ管理も型も別物 → JSは動的型付け言語であり、WASMは静的型付け言語のため呼び 出すたびに型変換・安全チェックが発生する。 • ccall/cwrapのラッパーが関数登録や例外処理を毎回行う → 呼び出しごとに変換・例外処理が走るため、小さい関数を大量に呼 ぶと遅くなる。 • JIT最適化が効かない → 境界部分はJIT最適化の対象外？ • 1回あたりは軽くても数が膨大 原因 最初の壁 ― JavaScript↔WASMの境界
7. • フレームごとに 1回だけデータをやり取りする • 最終的にポインタ渡しにしてオーバーヘッドがほぼゼロに JavaScript↔WASMの境界コストが消え、本来の C++性能 を発揮できるように！ 解決 最初の壁 ― JavaScript↔WASMの境界
8. • データ構造 → SoA化（Structure of Arrays）でキャッシュ効率UP • 探索処理 → KD-treeで近傍探索 • メモリ管理 → 固定ヒープで再確保を防止 • 処理の間引き → 重い処理を数フレームに1回に実行して負荷分散 • 並列化 → WebAssembly Threads＋スレッドプール化 内部最適化
9. 結果と気づき • 最初は「WASM＋C++なら速い」と思っていた。 でも実際は、データ構造やアルゴリズム設計が重要だった。 • 工夫次第で高速化を狙える。 • 何より、「すぐ使ってもらえる」のが大きな強み。 • まだまだ改善の余地があるのでさらに最適化して FPSを上げたい。