Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 21
все же native выигрывает по производительности
Примерно в 2 раза.
существует WAVM, которая заявляет немного другое)) https://wavm.github.io/
кстати, вы - отличный автор!
Wasm был нужен чтобы портировать тулзы других языков во что-то что может работать в вебе на клиенте по большей части
Сейчас это ллм делают в один промпт для любой техи и без wasm, так что вангую что он не приживётся где-то кроме глубоких б2бшек в виде легаси
спорный тезис)) LLM выдает недетрменированный результат, а построение loop из агентов (которые будут выдавать предсказуемы результат) будет сильно дороже для этой задачи.
Тем более LLM не решит проблему регулярного запуска чего то в изолированной среде.
WASM лучше использовать как инструмент для LLM, и наоборот. Например, https://t.me/prowasm/11 :)
Но тут полезно вспомнить, что лидер по компиляции и тулчейну для WASM - это Rust, а там корректность памяти обеспечена на этапе компиляции.
Ну, кто там лидер, Rust или C, особенно когда в браузер в лом лишние байты гнать - это можно долго обсуждать. А про обеспеченность чего-либо в Rust на этапе компиляции я очень сомневаюсь - без unsafe Rust работоспособен исключительно в corner cases. Да, я знаю, сочетание Rust с организационными мерами почти начинает что-то гарантировать, можете не кидаться этот ваш Rust защищать.
По поводу моделей, мои сугубо неверные любительские тесты скорости выполнения показали - у LuaJit и V8 она практически одинакова. Просто Lua, естественно, это беда, а Python - большая беда.
У WebAssembly, помимо отмеченного в статье, ещё способности обфусцировать код и обходить W^X политику. Последнее, например, позволяет (абы как) писать на С на iPad. Вот я и думаю, что именно эти две способности и определят будущее WebAssembly, а как именно политологи скажут лучше.
Наконец-то статья из моей ленты Гугла написана не ИИшкой...
Я не очень понимаю проблему с распределением регистров при компиляции стековой виртуальной машины, в особенности апелляцию к одному проходу. Всё равно есть стадия проверки, что глубина стека совпадёт в точках выполнения, в которые можно прийти разными путями кода. Будем считать эту стадию нулевым проходом. На этой стадии у каждой инструкции проставляется глубина стека перед выполнением инструкции, это число и обозначает регистр, соответствующий вершине стека, каждый элемент ниже по стеку обозначается числом на единицу меньше.
Мы проверяли на собственном большом проекте где важна производительность и получили аналогичные результаты. Кому интересно можно почитать наше расследование: https://habr.com/ru/companies/pt/articles/845624/
Тут буквально фундаментальный сдвиг с
- Хочешь полноценно платформонезависимое приложение - пиши все на js/java. И вот тебе тяжелый рантайм.
На
- Хочешь полноценно платформонезависимое приложение - пофиг на язык, просто компилируй под wasm
Я уверен, что wasm влезет на место электрона, докера, да и приложений на смартфоны. Как раз harmony на фоне мелькает.
Я с вами солидарен
Такие же заявления были 7 лет назад (плюс уже два года как «production ready» - цитата из статьи).
Но увы.
С приходом WASI 0.3 стал заметен явно положительный трек для использования WASM в качестве серверной технологии. По сравнению с 2019 годом есть заметные изменения)
Кажется, как замена докер контейнеров оно работает уже давно. Wasm контейнеры можно с докер хаба качать и в докере же запускать. Но до electron еще не дорос.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebAssembly (WASM) — не серебряная пуля