Comments 50
Или обрабатывать 4K-видео на слабом смартфоне
Как Wasm сделает смартфон мощнее?
только вроде при участии грааль вм наверно
Автор конечно загнул. Но если браузер у старых смартфонов обновляется, то можно попробовать SIMD (https://caniuse.com/wasm-simd), многопоточку (https://caniuse.com/wasm-threads), у wasm выше произовдительность для int-ов (если не вдаваться в детали, то в js все числа это double) и может что-то ещё затянут. 4K не вытянут, но может где-то получится выкрутиться по вычислениям для Web приложений и игр.
если не вдаваться в детали, то в js все числа это double
Если не вдаваться в детали, то современные JS-движки это дело все-таки оптимизируют и под капотом хранят int как int
в js все числа это double
Верно, стандарт языка делает такое заявление
4.4.23 Number value
primitive value corresponding to a double-precision 64-bit binary format IEEE 754-2019 value
но это не мешает реализациям, не выходя за границы этой абстракции, делать некоторые оптимизации. В частности, в V8 вводит отдельный тип Smi (Small Integer) для целочисленных значений, умещающихся в 31 бит.
Эксперты предсказывают: к 2030 году Wasm станет стандартом для кроссплатформенных приложений, заменив собой Java-апплеты и Flash
Да эксперты просто молодцы!
Если что, апплетов нет с 2017 года (https://en.wikipedia.org/wiki/Java_applet), а Flash c 2020 (https://en.wikipedia.org/wiki/Adobe_Flash)
Как-же режет глаз GPT-стиль.
Ну вот про C# то же самое говорили. Или про Java - что, кстати, почти оправдалось.
Реально встречаются Java-приложения, сложные - и работающие на любой платформе.
Вопрос же не в том, чтобы скомпилировать (этот вопрос давно закрыт с появлением llvm) - вопрос в том, чтобы предоставить разработке стандартное, универсальное API для работы. И чем оно более полное - тем сложнее и глючнее.
И да: если нужен "просто код" или "просто алгоритм" - так для этого можно или написать на интерпретируемом языке, или исходники предоставить. Все проблемы начинаются, когда хочется сделать "красиво". И интегрировано в нативное окружение.
Если вы ещё не пробовали Wasm — самое время начать.
Половина россиян уже пробовали, а то и больше. После удаления приложений из сторов на wasm банки начали массово переходить. См. - https://habr.com/ru/amp/publications/686408/
Не знаю, что тут уже такого сенсационного
Поиграйтесь с WasmFiddle.
ссылка слегка неиграбельна)
Сколько я ни смотрел бенчмарков, везде преимущество в скорости WASM было скажем так неочевидно. Да, в узких кейсах может быть преимущество 2-3-5х (откуда автор взял 10х?), но глобально по больнице - приблизительный паритет, иногда даже немного медленнее было. Оговорюсь, что смотрел я это год-два назад, может сейчас что-то поменялось.
И насчет Фигмы, которую очень часто приводят в пример. Читал я где-то пост (вот не помню источник, к сожалению) - там автор писал, что своим хорошим перфомансом Фигма обязана совсем другим вещам, а именно WebGL и прямым рукам разработчиков с хорошей алгоритмической подготовкой (которая, как известно, никому не нужна кроме собесов). А WASM, сообщал тот же автор, там был нужен совсем для другой цели - на нём сделана безопасная песочница для плагинов, потому что исполнять у себя на машине рандомный JS-код так себе идея.
Сам я это ни подтвердить, ни опровергнуть не могу. Но если кто-то может - это было бы интересно почитать вместо общих слов и агиток.
webGL иной раз у меня по лучше ПК версии почему-то работает,а может мои приложения на ПК не ок, https://webglfundamentals.org/webgl/lessons/webgl-fundamentals.html, васм есть в сдл знаю(по крайней мере есть возможность С++ превратить в васм, там правда надо ставить какой-то комплекс утил для этого ), или в грааль тогда наверно писать не знаю ниразу не ставил задачи васм запускать, так можно и Clojure сразу думать у него принцип как у васма почти, синтаксис только другой
WASM - это в первую очередь про использование существующей кодовой базы на других языках без переписывания на js.
А WASM, сообщал тот же автор, там был нужен совсем для другой цели - на нём сделана безопасная песочница для плагинов, потому что исполнять у себя на машине рандомный JS-код так себе идея.
Что WASM-байткод, что JS-код выполняются в песочнице. То, каких дел они могут наделать на вашей машине, определяется в обоих случаях исключительно тем, биндинги каких именно системных API вы пробросите им в среду выполнения. Короче говоря, в плане безопасности исполнение рандомного JS-кода и рандомного WASM-байткода не отличается вообще никак.
А сами авторы Figma у себя на сайте прямо говорят, что WASM взяли именно из-за перформанса, и даже бенчмарки всякие показали: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
Wasm хорошо решает вопрос производительности только в случае отдельных выделенных служб, где необходимы операции с плавающей точкой, например. А это достаточно узкие кейсы, далеко за рамками потребностей большинства обычных веб приложений. Ох уж мне эти wasm-революционеры... Вы сначала сами попробуйте сделать что-то на wasm, посмотрите на размер сборки, измерьте скорость на живом примере, покурите, подумайте...
@А что, если нейросеть на сайте будет работать в 20 раз быстрее?
Это как? Нет, разумеется, если где-то нейросеть пашет на голом Javascript прямо внутри пользовательского браузера, то ускорение может и будет. Но это же в природе не встречается, и обычно все ресурсоемкое крутится в бэкенде и пишется на чем-либо максимально шустром.
Как там, уже сделали на WASM ZIP архиватор который быстрее написанного на JS?
Делал на js - sax парсер xml . Так вот работает он быстрее в разы(в 7-10 раз) чем бинарный expat или libxml.
WebAssembly нужная технология, но очень специфичные. И точно не серебряная пуля
Не понимаю одного: почему они тянут с доступом в DOM?
Потому что может случиться 10х, но в обратную сторону:)
Работа с DOM это на 99% вызов функций браузера, которые принимают и возвращают очень развесистые объекты с огромным количеством полей (посмотрите на состав DOM Node). Компилятор JS видит, что коду из этого всего реально нужно 2-3 поля, знает кишки своего браузера и может неслабо так соптимизировать. А с васмом будут бесконечно байты перекладывать.
Передать объект по ссылке/указателю нельзя?
Нельзя. Нарушается принцип песочницы.
wasm компилятор при генерации кода может определить, что можно а что нельзя делать с данными по переданному указателю. А если быть последовательно параноидальными, песочницу надо вообще в отдельную виртуалку выносить.
wasm компилятор при генерации кода может определить
В общем случае не может. Потому пока идут обсуждения, чтобы предоставить доступ к DOM через новое API, более гранулярное.
На уровне wasm'овского байткода DOM вполне может быть opaque объектом с доступом через аксессоры, но при генерации машинных инструкций движок в конкретном браузере может эти вызовы оптимизировать в обращения по фиксированным смещениям от переданного указателя в соответствии с layout'ом внутренних структур.
Каким это образом?
Тем, что код в песочнице получит доступ к области памяти вне песочницы.
Нет там такого. Память песочницы также виртуальна как и "процессор"
Потому что может случиться 10х, но в обратную сторону:)
Скорость во фронтенде не главное, главное - избавиться от JavaScript
У меня такой же вопрос и отсутствие адекватного ответа порождает разные теории заговора о том, что разработчики браузера просто большие фанаты JavaScript и не хотят его хоронить. Вытащили же по политическим причинам совершенно не предназначенный для этого изначально язык в сферу больших и универсальных проектов.
Еще один таргет для компиляции, возможно самый универсальный, и самый распространенный в будущем.
Java-апплеты и Flash
Я не ослышался?
А что, если нейросеть на сайте будет работать в 20 раз быстрее?
Она будет постить на Хабре в 20 раз больше таких статей.
Раз тут ещё не написали - Docker - это не про изоляцию. Docker это про гарантированную среду с гарантированной конфигурацией. Изоляция там вторична. Поэтому сравнение совсем не в кассу.
С Wasm можно действительно интересные вещи творить. Например, вот ребята даже распознавание видеопотока в браузере сделали. Сейчас это во всех банках используется, вроде как
Figma: Весь редактор работает на Wasm — это позволило отказаться от десктопных приложений
Да не, он лагает и вылетает. Но может в ближайшем будущем...
WebAssembly: Как «невозможное» стало реальностью?