WebAssembly (WASM) позволяет запускать скомпилированный код (например, на AssemblyScript) вместе с JavaScript/TypeScript, в нашем сегодняшнем примере, я буду использовать накиданную мной стуктуру для тестов и экспериментов. Изучить её можно тут (пока что затрагиваем только серверную часть): клик.
Для каждой задачи есть две версии:
Функции решают следующие задачи:
Также используется функция сложения для проверки правильной работы модуля.
Результаты тестов (первый набор)
При небольшом числе итераций разница между версиями почти незаметна. Здесь JavaScript-код, собранный через esbuild для ноды 14.10, показывает хорошую скорость работы с числами с плавающей точкой, а версия на WASM выигрывает в случае работы с целыми числами.
Результаты тестов (обновлённый набор с увеличенными значениями)
При очень большом числе итераций для вычисления π версия на WASM становится почти в 77 раз быстрее. Это показывает, что оптимизированный код на WASM справляется лучше с большими объёмами вычислений. Для задачи подсчёта простых чисел разница между версиями почти не видна, так как оптимизированный JavaScript-код уже достаточно быстро выполняет циклы и проверки.
Рекомендации по использованию WASM в RAGE:MP
Лучше всего использовать ассемблер если задачи требуют огромного числа математических операций, тут по скорости победителем будет WASM.
Так-же если у вас есть много выполняющихся операций (численные расчёты или обработку данных), то лучше такую логику вынести в WASM чтобы не забивать основной поток джава-скрипта.
PS. Мне бы хотелось от других ребят тоже услышать где ещё теоретически можно использовать WASM в реалиях RAGE:MP.
Когда не использовать WASM
Если у вас происходят часто мелкие вызовы где нету тяжелой логики просчёта или чего-то ещё, то это наоборот будет только губить производительность вашего сервера.
Так-же вы не можете написать всю логику сервера на WASM, потому что его код исполняется в среде с множеством лимитов и ограничений. Вы не можете испольовать HTTP запросы, не можете взаимодействовать с файлами системы а так-же интернет составляющей в WASM. Для этого вам в любом случае нужно использовать JS (Host) и прокидывать всё в ассебмлер.
В общем и целом, используйте ассемблер для ускорения математических расчётов, а для операций ввода-вывода и небольших вычислений лучше всё так-же использовать JS.
WASM не панацея, но и не яд.
PS. Вообще, к использованию WASM я додумался совершенно случайно, когда уже столько времени думаю как защитить сорсы от слива и сделать так, чтобы имея исходники но не имея лицензии, слитый код превратиться в арбуз, и вот захотелось потестить ассемблер. В целом, код всё так-же можно разобрать предварительно конвертнув .wasm файл в .wat (лоу-левел код т.е текстовая инструкция) и скормить какой нибудь нейронке на анализ. Логика на таком этапе будет понятна для чтения разработчику и соответственно он сможет вырезать места где используется ассемблер и переписать эти части кода. Конечно на это потребуется время, если логики достаточно много, и потенциального аттакера это может затянуть по времени. Т.е для условной обфускации, это сработает. Но, процесс уже будет запущен и это только вопрос времени, когда в вашей слитой сборке изменят вызовы функций.
Спасибо всем кто дочитал до этого момента, эта статья несет исключительно информативный характер для экспериментов, анализов и проб. Если есть какие нибудь идеи по поводу возможной защиты кода, мне было бы интересно это обсудить)
Описание тестов и сравнительный анализ
Реализация функций
Для каждой задачи есть две версии:
- TypeScript: обычная версия на TS, которая компилируется в JS с помощью esbuild. клик
- AssemblyScript (WASM): версия с аналогичной логикой, преобразованная в WebAssembly. клик
Функции решают следующие задачи:
- Вычисление числа π по формуле Лейбница: суммирование ряда с чередующимися знаками, после чего результат умножается на 4.
- Подсчёт простых чисел: перебор чисел с проверкой делимости (метод «Trial Division»).
Также используется функция сложения для проверки правильной работы модуля.
Результаты тестов (первый набор)
При небольшом числе итераций разница между версиями почти незаметна. Здесь JavaScript-код, собранный через esbuild для ноды 14.10, показывает хорошую скорость работы с числами с плавающей точкой, а версия на WASM выигрывает в случае работы с целыми числами.
Результаты тестов (обновлённый набор с увеличенными значениями)
При очень большом числе итераций для вычисления π версия на WASM становится почти в 77 раз быстрее. Это показывает, что оптимизированный код на WASM справляется лучше с большими объёмами вычислений. Для задачи подсчёта простых чисел разница между версиями почти не видна, так как оптимизированный JavaScript-код уже достаточно быстро выполняет циклы и проверки.
Рекомендации по использованию WASM в RAGE:MP
Лучше всего использовать ассемблер если задачи требуют огромного числа математических операций, тут по скорости победителем будет WASM.
Так-же если у вас есть много выполняющихся операций (численные расчёты или обработку данных), то лучше такую логику вынести в WASM чтобы не забивать основной поток джава-скрипта.
PS. Мне бы хотелось от других ребят тоже услышать где ещё теоретически можно использовать WASM в реалиях RAGE:MP.
Когда не использовать WASM
Если у вас происходят часто мелкие вызовы где нету тяжелой логики просчёта или чего-то ещё, то это наоборот будет только губить производительность вашего сервера.
Так-же вы не можете написать всю логику сервера на WASM, потому что его код исполняется в среде с множеством лимитов и ограничений. Вы не можете испольовать HTTP запросы, не можете взаимодействовать с файлами системы а так-же интернет составляющей в WASM. Для этого вам в любом случае нужно использовать JS (Host) и прокидывать всё в ассебмлер.
В общем и целом, используйте ассемблер для ускорения математических расчётов, а для операций ввода-вывода и небольших вычислений лучше всё так-же использовать JS.
WASM не панацея, но и не яд.
PS. Вообще, к использованию WASM я додумался совершенно случайно, когда уже столько времени думаю как защитить сорсы от слива и сделать так, чтобы имея исходники но не имея лицензии, слитый код превратиться в арбуз, и вот захотелось потестить ассемблер. В целом, код всё так-же можно разобрать предварительно конвертнув .wasm файл в .wat (лоу-левел код т.е текстовая инструкция) и скормить какой нибудь нейронке на анализ. Логика на таком этапе будет понятна для чтения разработчику и соответственно он сможет вырезать места где используется ассемблер и переписать эти части кода. Конечно на это потребуется время, если логики достаточно много, и потенциального аттакера это может затянуть по времени. Т.е для условной обфускации, это сработает. Но, процесс уже будет запущен и это только вопрос времени, когда в вашей слитой сборке изменят вызовы функций.
Спасибо всем кто дочитал до этого момента, эта статья несет исключительно информативный характер для экспериментов, анализов и проб. Если есть какие нибудь идеи по поводу возможной защиты кода, мне было бы интересно это обсудить)
