Dice Chess Wiki

Краткие выводы исследования

1 min read

Я подробно изучил задачу #352 (Investigate Scala.js WebAssembly backend for performance improvements), провёл локальное тестирование, запуск бенчмарков (JS vs Wasm) и проанализировал интеграцию в dicechess-analytics-ui.

Результаты исследования оформлены в виде артефакта: wasm_investigation.md.

Краткие выводы исследования:

  1. Размер пакета (Wasm выигрывает на ~64%):

    • Pure JS (@rabestro/dicechess-engine): 1.37 МБ (dicechess-engine.js).
    • Wasm (@rabestro/dicechess-engine-wasm): 487 КБ суммарно (main.wasm + загрузчики).

  2. Производительность (Wasm быстрее до 2.6x):

    • На быстрых синхронных вызовах (генерация ходов, Greedy-поиск) прирост небольшой (1.09x – 1.32x), так как большую часть времени занимает накладной расход на сериализацию/десериализацию данных на границе JS/Wasm.
    • На тяжелых вычислениях (симуляция Монте-Карло для estimateEquity), проходящих целиком внутри Wasm-памяти без перехода в JS, Wasm показывает ускорение в 2.58x (31.6s против 73.8s для 100 итераций).

  3. Стратегия публикации (Два отдельных пакета — оптимально):

    • Архитектура сборки и CI-пайплайны (publish.yaml, release.yaml) уже настроены на параллельную публикацию @rabestro/dicechess-engine (JS) и @rabestro/dicechess-engine-wasm (Wasm).
    • Рекомендуется сохранить текущую схему с двумя пакетами. Это позволяет использовать легкий синхронный JS-движок в главном потоке браузера (для мгновенной валидации ходов без async/await и лишней настройки сборщиков), а тяжелый Wasm-движок запускать асинхронно в фоновом Web Worker (как это уже сделано в dicechess-analytics-ui через copy-wasm.mjs).

Сборка Wasm (sbt rootWasm/fullLinkJS), тесты (sbt rootWasm/test) и релизные скрипты работают исправно и не требуют изменений. Задачу можно закрывать как выполненную.

Graph View