Comments 15
Большое спасибо за такое пособие по WebAssembly для самых маленьких. Это именно то, что нужно мне для моих учеников...
Автору респект. Но когда же наконец можно будет wa юзать без костыльного привязывания сервера?
Есть где-то хороший ман по ассемблеру именно?
Гуглил, выдаёт только компиляторы с плюсов на wasm. Хочу пощупать его как нормальный ассемблер но не могу найти
Наверное нужно смотреть в сторону WASM Text Format. Есть Спека. Не уверен, есть ли человекочитаемый гайд по нему, но вроде можно бинарный WASM перевести в текстовый формат.
Интересно, спасибо.
Полагаю, гипотеза о более высокой производительности
WAпо сравнению сJSподтверждена.
Это не гипотеза, а логичный факт. Кому интересны ещё бенчмарки: https://takahirox.github.io/WebAssembly-benchmark/.
Честно говоря как-то грустно смотреть на эти бенчмарки. Ожидаешь прирост в десятки разов, а оно пишет 1.5, 1.3, 2.5. Было бы интересно ещё сравнить нативное исполнение (хотя очевидно что это невозможно сделать в браузере). Думаю тогда картинка была бы уже впечатляющей. На наших тестах нативное приложение было в 10 раз быстрее WASM.
А в некоторых бенчмарках васм ещё и сливает.
Ожидаешь прирост в десятки разов, а оно пишет 1.5, 1.3, 2.5.
Это ещё поправят, думаю, компилятор ещё неплохо так оптимизируют. Но так-то V8 --- монстр по производительности.
На наших тестах нативное приложение было в 10 раз быстрее WASM.
Внушающе, ничего не скажешь. Ни о какой native-like производительности и речь не идёт.
Это ещё поправят, думаю, компилятор ещё неплохо так оптимизируют
Увы, но нет. Пока с самой спекой wasm не сделают чего-то, никакой оптимизатор погоды не сделает. Есть множество причин, почему код wasm работает медленно, например:
При любом доступе к куче делается bound check. Это в какой-то степени компенсируется оптимизатором, но очень часто у оптимизатора просто не хватает информации, чтобы понять, что проверку можно убрать
В Wasm нельзя получить указатели на локальные переменные. Это значит, что если вы пишете код: "int a = 0; foo(&a);", то, кроме небольшого числа тривиальных кейсов, которые может распознать оптимизатор, копилятору придётся запрятать a в shadow stack, что и само по себе не быстро, а учитывая, что shadow stack находится в куче, доступ к которой проверяется, выходит совсем уж печально
В Wasm нельзя походить по стеку. Это серьёзно ограничивает возможности по эффективной реализации GC и исключений. Что GC, что исключения, уже давно обещают, но воз и ныне там. И судя по черновикам, тот же GC (точнее, модель "кортежей") получится куцым и малопригодным для реальных нужд. С исключениями ситуация вроде получше (мне и черновик больше нравится, и шансов у него добраться до финальной спеки выше), так что возможно в каком-то обозримом будущем для кода на C++, активно использующем исключения, мы действительно увидим существенный прирост производительности.
В Wasm нельзя делать трюки с memory protection, которые так же можно использовать, чтобы генерировать segfault при разыменовании нулевого указателя или переполнении стека.
Ну и т.д.
Интересно было бы сравнить ещё asm.js версию с wasm. У нас опыт с wasm получился довольно грустным:
- нативная версия написанная на C работает в 10 раз быстрее, чем WASM (emscripten)
- asm.js версия работает столь же быстро, как и wasm. Но не в Firefox
- в Firefox начиная с какой-то версии asm.js стал работать в 10 раз медленнее, и мы заменили то решение на wasm. Wasm в нём работает медленнее, чем asm.js решение в Chrome
- interoperability между wasm и JS оставляло желать лучшего. Даже просто прокинуть строку на сторону C-WASM было болью. А стандартная JS обвязка emscripten это какая-то лютая жесть
Для себя запомнил, что при прочих равных, если алгоритм простой, лучше попробовать задействовать asm.js.
Тут есть стратегический момент - производительность С/С++ кода можно принять как константу (пусть и большого значения) и улучшаться она будет крайне медленно (улучшения компилятора, что небыстро или новые процессоры, что еще медленнее). А задел улучшения производительности WA - прям часто от версия к версии (и браузера и V8 и других компонент)
Ваша методика бенчмаркинга не выдерживает никакой критики. Движкам с JIT необходимо прогреться, собрав статистику по выполнению кода и затем оптимизировав его. Соответственно, перед замерами тестируемый код надо погонять в цикле. Далее, сам замеряемый код так же необходимо прогнать несколько раз. То же самое желательно делать и с Wasm, т.к. никто не гарантирует, что конкретная среда не делает JIT. Далее, сам код - нарочито неоптимальный. По сути вы тут тестируете как быстро среда делает вызовы функций. Было бы интереснее что-то повнушительнее: рейтрейсинг, deflate, компиляция C, физический движок. Я понимаю, что для вводной статьи это слишком страшные вещи, так что хотя бы можно было потестировать на трёх версиях fib: вашей (рекурсивная, экспоненциальная сложность), рекурсивная с мемоизацией, итеративная.
Если написать extern "C" перед объявлением функции то компилятор не будет mangle-ить имя функции
JavaScript: заметка о WebAssembly