Как стать автором
Обновить

Комментарии 11

Тоже потратил много времени, разбираясь с wasm, толи быстрее, толи нет. Прочитал книгу, написал тесты, попробовал в рендере графики, вывод получился такой: обертки для сложных структур могут сильно замедлить wasm, а в равных условиях производительность очень близка.

А вы пробовали для wasm делать вычисления в f32 вместо f64. Полагаю точности первого должно хватить для использования шума в играх.

Подытожить данное приключение хочется тем, что Wasm, как более низкоуровневая технология, безусловно будет быстрее.

WASM- это, скорее, не про ускорение JS а про смерть JS. На данном этапе WASM просто как некое дополнение к JS выглядит, но в перспективе туда добавят прямой доступ к DOM, сборщик мусора и пр. - и это уже будет не просто дополнение а автономно существующая и не зависимая от JS подсистема. Основной плюс - можно писать на любом ЯП, т.е. машина прогибается под человека а не наоборот.

Честно говоря, уже очень сомнительно такое будущее видится. Очень медленно все идет, а единственный, кто толкает жс+другие языки - bun.

Wasm, действительно, изначально задумывался как возможность ранить что-то более низкоуровневое, чем JS, с доступом к памяти, но прямо в веб-браузере. Однако, ее кроссплатформенность, очевидно, становится более предпочтительным плюсом.

Из-за чего лично я с нетерпением ожидаю взлет популярности раскрутки WASI и пакетного менеджера Wasmer, условная попытка раз и навсегда разобраться с необходимостью иметь все виды компиляторов C/C++, make, cmake и тд, чтобы не просто запускать код в брувзерах, а иметь возможность собирать проект на разных языках прямо на хост из исходников чисто засчет того, что Wasm будет выступать как именно кроссплатформенный унифицированный стандарт. Своеобразный доцкер, только без GC. Это ли не пушка?

Так ведь есть уже для этого "взлетевшее" решение, JVM называется.

JVM не подойдёт для C/C++/Rust/Go/Zig... А тут идея того, что на чем (почти что) не пиши - собираешь на любой комп без кучи симэйков и нужных версий компиляторов

Почему не подойдёт? Вроде тоже виртуальная машина с байткодом, как и WASM.

Ну да, сам wasm это скорее спецификация. Виртульной машиной наверное можно назвать какой-то wasmtime. Но в общем-то смысл же тот же, что и в jvm - компилим один раз в байткод и запускаем везде.
Даже ограничения похожие - нет прямого доступа к окружению, только через интерфейсы "рантайма"

Rust-код в статье выглядит сильно неоптимальным. Именно, он на каждой внутренней итерации преобразовывает rust-овый Vec в массив JS, что подразумевает копирование и боксинг данных (каждого отдельного числа), а потом итоговый Vec копируется ещё раз при переводе в значение Javascript. Это очень много лишних операций. Лучше было бы на стороне Rust предаллоцировать массивы и потом их заполнять - или, ещё лучше, использовать типизированный Float64Array и избежать конвертации вовсе. Правда, такой типизированный массив придётся делать плоским, что может повлиять на удобство со стороны Javascript

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории