Комментарии 13
Расслабленный SIMD, это что-то новое для меня. SIMD который не напрягается :) Хотя тот SIMD что есть в Wasm и в правду ненапряжный.
Вот всегда в таких статьях "как мы покоряем просторы вселенной" говорится о больших фичах, но всегда не обращается внимание на то, что "есть нюанс". Например, GC они выпустили, ага. Только там почему-то дереференс nullptr приводит к trap-у, а не к исключению, что полностью противоречит поведению в подавляющем числе мейнстримных языков с управляемой кучей (JS, Java, C#, Python); аналогично с делением на ноль или с neg для -0x100000000. Или вот GC не поддерживается ни в одном известном мне безбраузерном движке. Или что до сих пор не выпустили никакого стандарта debug информации, а поддержка DWARF (где она есть) сырая просто до неюзабельности и вообще не вполне стандартизирована (я как автор компилятора в WASM лично сталкивался с тем, что wasmtime и chrome понимают DWARF по-разному). Ну и что DWARF идеологически никак не ложится на языки с GC. Или что ничего близко к "нативной производительности" в WebAssembly и не пахнет, что его "куча" спроектирована так, что любое обращение к памяти неминуемо обкладывается проверками на рантайме, и как авторы этих рантаймов героически пишут оптимизации, призванные количество этих проверок хоть как-то снизить.
Зато, о чудо, реализовали хвостовую рекурсию, всё многочисленное сообщество программистов на OCaml будет довольно этой новости.
Ирония судьбы: WebAssembly был создан для ускорения кода в браузерах, а теперь мы движемся к тому, чтобы компилировать JavaScript обратно в WebAssembly!
WebAssembly медленно но верно завоевывает мир, слишком уж много у него преимуществ. Писать логику на расте для браузера вместо джава скрипта это как благословение с небес.
Переиспользовать можно 95% одного и того же кода на всех платформах сразу: браузер, мобила, сервер - это просто супер преимущество, тут конечно больше спасибо расту, но тем не менее.
Не сегодня-завтра всем понадобится запускать ИИ модели у себя в браузере или на мобиле и производительность там играет решающее значение, wasm и тут должен стать незаменим. Можно видеть зачатки этого всего в hugging face candle.
В общем, докер в браузере уже не за горами (на wasm-е конечно же). Stackblitz работает над этим https://webcontainers.io/
С wasm наконец можно будет сделать хороший serverless победив проблему cold start. Собственно у cloudflare уже все хорошо в этом плане, workers-rs уже пару лет как в продакшене
Можно ненадо?
Писать логику на расте для браузера вместо джава скрипта это как благословение с небес
Эээ, нет.
Переиспользовать можно 95% одного и того же кода на всех платформах
сразу: браузер, мобила, сервер - это просто супер преимущество, тут
конечно больше спасибо расту, но тем не менее.
Это совсем не уникальное преимущество WASM или Rust.
Не сегодня-завтра всем понадобится запускать ИИ модели у себя в браузере
или на мобиле и производительность там играет решающее значение, wasm и
тут должен стать незаменим.
Эээ, я думал, ИИ-модели запускают на CUDA, при чём тут WebAssembly? Может, в данном случае лучше предусмотреть CUDA API или хотя бы OpenCL API для браузера?
>Эээ, нет
Да! (ваш уровень аргументации мне нравится, что ж буду пользоваться тем же приемом)
>Это совсем не уникальное преимущество WASM или Rust.
Примеров конечно же не будет приведено в качестве аргумента?
>Эээ, я думал, ИИ-модели запускают на CUDA, при чём тут WebAssembly?
при том, что если вы сможете запустить модель из браузера и получить ту же производительность, что и если вы запустите из питона используя cuda, это будет невероятное преимущество в плане простоты для конечного пользователя
Да! (ваш уровень аргументации мне нравится, что ж буду пользоваться тем же приемом)
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Примеров конечно же не будет приведено в качестве аргумента?
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
при том, что если вы сможете запустить модель из браузера и получить ту
же производительность, что и если вы запустите из питона используя cuda
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?
>Rust - это более низкоуровневая штука
К счастью вы тут не правы, с точки зрения высокоуровневости языка rust выше джавы (с ратсом я работаю 2 года с джавой 15 лет). Например в паттерн матчинге, в плане работы с ADT он дал фору даже scala (у меня 3 года опыта со scala). Я бы сказал rust примерно на уровне kotlin-a
>А вот писать то, для чего обычно используют JS,
на жс можно спокойно продолжить писать веб компоненты, но всю логику работы - запросы к бакэнду и прочее связанное именно с логикой а не html-е на rust писать на порядок приятнее, в первую очередь из-за мощной системы типов, которая в большинстве случаев легко сравнится с scala, о чем не приходится мечтать ни жс ни тайпскрипту
>Но фанатам Rust, конечно, так не кажется
я лично фанат раста, скалы, джавы и джава скрипта одновременно, поэтому ваш аргумент в данном случае не является валидным
>Java: на сервере и в Android из коробки
А IOS не из коробки, и вот у нас уже появляется два языка - котлин(джава) и свифт, а мог бы быть раст и совсем чуть чуть котлина и свифта. Мы кстати именно так и делаем сейчас, за UI отвечает: [kmm(compose) | vue/typescript ] + rust (90% вся логика)
>Google Closure Compiler...
вы перечислили просто огород технологий, ровно то о чем я и говорил. То есть теперь у нас айос, джава, и еще и кожура в списке появилась и веб ассембли до кучи)
>Python - из коробки на сервере
хоссподи помилуй)
>WebAssembly как-то умеет работать на GPU?
Я же вам ссылку на обсуждение скинул. Если жс и браузер умеют использовать GPU то и васм умеет. Я так понимаю WebGpu обещает быть в этом плане решением, но я в это не погружался, сказать не могу на сколько там все плохо или хорошо.
Если васм сможет работать с моделями используя GPU то и жс по определению сможет, тут нет претензий к жс в этом плане, просто ждем когда браузеры смогут это делать. А вот в плане удобства strong types и вот это вот все, раст будет намного более удобным инструментом.
Состояние WebAssembly – 2023 и 2024