WebAssembly | Когда и как использовать ? | Сравнение скорости с JavaScript | Почему не убил JS?

[@artwelf]

Немного некорректен тест на перебор массива. Вы в Rust-коде используете строго типизированный массив, а в JS используете Array. У строго типизированных массивов с фиксированной длиной производительность гораздо выше, так как они хранятся в стеке (их размер известен в момент компиляции), а вот для массивы, длина которых не известна в момент компиляции, хранятся в куче. Доступ в стек наша программа имеет напрямую, а вот в кучу она может обращаться только лишь через операционную систему, что добавляет задержку. Логичнее было бы либо использовать в Rust-коде вектор, либо в JS тоже использовать строго типизированный массив Int32Array.

[@hrustalevdev]

Спасибо большое! Очень познавательно!

[@AndreyChuprin0101]

Всегда пожалуйста) Рад, что вам было полезно)

[@kibinnaneko3989]

Было очень интересно, спасибо за видео

[@AndreyChuprin0101]

Очень рад, что вам понравилось )

[@VladislavFilippov-u7p]

очень интересно, спасибо

[@eugenekalashnikov9331]

Спасибо, информативно. Webasembly, например, используется в mitek SDK

[@AndreyChuprin0101]

И вам спасибо )

[@mqxim630]

спасибо за такой крутой урок! сделайте пожалуйста урок по работе с канвасом через webassembly (как сейчас работает фигма)! будет очень интересно узнать

[@АндрейК-с5в]

Figma на нем работает, если не ошибаюсь. На чистом JS такого не сделать, в принципе. Так что думаю фишка WA далеко не в скорости перебора цикла или операций сложения.Но canvas, вышедший в html5, в принципе закрывает большинство потребностей делая WA не сильно востребованным.

[@AndreyChuprin0101]

Я пытался показать на примере простых операций преимущество в скорости. Но ведь высокая производительность нужна не только при работе с изображениями, + можно WA использовать и для работы с canvas, просто далеко не везде нужна такая оптимизация

[@alexperemey6046]

Сделать, в Фигме ничего нет такого, с чем бы не справился Js. В конце концов производительность 50% - это не та цифра, чтобы говорить о том, что есть принципиальные задачи, которые не доступны Js, но доступны WebAssembly...

[@alexperemey6046]

Веб Ассембли же не умеет взаимодействовать с ДОМ, при чем тут канвас. Веб Ассембли будет что-то считать, а рисоваться все будет все равно на канвасе. Со скоростью Канваса. Или на ВебГл, со скоростью ВебГЛ. Т.е. в графике далеко не js является точкой, где возникают тормоза. Веб Ассембли может соревноваться с js на операциях, когда надо тупо посчитать что-то длинное, отдельно в вакууме, без взаимодействия с интерфейсом. Это не очень частое применение.

[@myaccount2611]

Я думаю, что в первом примере компилятор оптимизирует простой цикл до b = arg * 2;

[@alexperemey6046]

Вроде ж есть AssemblyScript который позволяет переводить в WebAssembly Typescript. Typescript в промышленном программировании фактически Js заменил. Так может все-таки есть смысл компилировать Typescript в WebAssembly и таки избавиться от js ?

[@ЕвгенийАнисифоров-щ9р]

А что меняется ts это тот же js только с типами

[@IvanSen-pv6bu]

Почитайте внимательнее описание AssemblyScript. Он от ТСа наследует только типизацию и синтаксис, но ничего общего в прямом смысле этого слова не имеет ни с жсом, ни с тсом. К слову, я даже нейросетки примитивные писал на AS, но скажу честно, AS почти не развивается на фоне раста и плюсов, на расте и плюсах хотя бы какое-то развитие в сторону васм идёт, создаются либы и т.п.

[@ashimov1970]

Тут выиграл Rust а не WASM. Тот же Blazor (C# + WASM) намного проигрывает в скорости JS фреймворкам.

[@AndreyChuprin0101]

Боюсь, что вы не правы. Объясняю: Данное приложение никоим образом не может взаимодействовать с Rust напрямую. Rust лишь компилируется в Wasm, который и работает в браузере, а мы, в свою очередь, лишь используем определённый интерфейс для взаимодействия с Wasm в приложении. Выполнение кода Wasm (если он скомпилирован из другого языка) может зависеть лишь от компилятора, а если быть точнее - от того, насколько правильно был скомпилирован код. То есть - возможно проблема в blazor, с ним я непосредственно не знаком. А почему именно фреймворки, в чем они именно быстрее и какие именно фреймворки ?

[@ashimov1970]

@@AndreyChuprin0101 глянь видео "Blazor wasm VS Angular. Катастрофический результат сравнения"

[@AndreyChuprin0101]

@@ashimov1970 ​ Просмотрел и почитал о Blazor немного - проблема именно в нем, он лишь использует обертку WASM, а потом как-то соединяет среду выполнения .NET и браузера, я не сильно углублялся в механизм за счет которого это все дело работает, но суть в том, что код C# не выполняется прямо в баузере в привычном понимании. А если использовать wasm-pack - он компилирует код Rust в WASM, с которым уже и работает браузер. Непосредственно на прямую в браузере запускается либо JS, либо WASM, другого не дано - 100%. А сам WASM вполне успешно используется на довольно крупных и успешных проектах: Figma, AutoCAD и т.д.

[@AndreyChuprin0101]

@@ashimov1970 тут дело не в самом C# или Rust, дело именно в реализации. + на одном из открытых источников встретил такое вот предложение о Blazor: "Файлы, загруженные браузером, имеют большой размер, что влияет на увеличение нагрузки сети и на время загрузки в целом, так как приложения работают на стороне клиента", это может объяснить долгую загрузку в начале у автора.

[@AndreyChuprin0101]

@@ashimov1970 Но в любом случае - спасибо вам. Я впервые увидел такой способ реализации, мб где-то будет для меня полезным).

[@DmitryMuromtsev-b1c]

0 мс, цикл проходит моментально? чудеса да и только...

[@AndreyChuprin0101]

Нет, не моментально) Есть величины меньше мс)