Немного некорректен тест на перебор массива. Вы в Rust-коде используете строго типизированный массив, а в JS используете Array. У строго типизированных массивов с фиксированной длиной производительность гораздо выше, так как они хранятся в стеке (их размер известен в момент компиляции), а вот для массивы, длина которых не известна в момент компиляции, хранятся в куче. Доступ в стек наша программа имеет напрямую, а вот в кучу она может обращаться только лишь через операционную систему, что добавляет задержку. Логичнее было бы либо использовать в Rust-коде вектор, либо в JS тоже использовать строго типизированный массив Int32Array.
спасибо за такой крутой урок! сделайте пожалуйста урок по работе с канвасом через webassembly (как сейчас работает фигма)! будет очень интересно узнать
Figma на нем работает, если не ошибаюсь. На чистом JS такого не сделать, в принципе. Так что думаю фишка WA далеко не в скорости перебора цикла или операций сложения.Но canvas, вышедший в html5, в принципе закрывает большинство потребностей делая WA не сильно востребованным.
Я пытался показать на примере простых операций преимущество в скорости. Но ведь высокая производительность нужна не только при работе с изображениями, + можно WA использовать и для работы с canvas, просто далеко не везде нужна такая оптимизация
Боюсь, что вы не правы. Объясняю: Данное приложение никоим образом не может взаимодействовать с Rust напрямую. Rust лишь компилируется в Wasm, который и работает в браузере, а мы, в свою очередь, лишь используем определённый интерфейс для взаимодействия с Wasm в приложении. Выполнение кода Wasm (если он скомпилирован из другого языка) может зависеть лишь от компилятора, а если быть точнее - от того, насколько правильно был скомпилирован код. То есть - возможно проблема в blazor, с ним я непосредственно не знаком. А почему именно фреймворки, в чем они именно быстрее и какие именно фреймворки ?
@@ashimov1970 Просмотрел и почитал о Blazor немного - проблема именно в нем, он лишь использует обертку WASM, а потом как-то соединяет среду выполнения .NET и браузера, я не сильно углублялся в механизм за счет которого это все дело работает, но суть в том, что код C# не выполняется прямо в баузере в привычном понимании. А если использовать wasm-pack - он компилирует код Rust в WASM, с которым уже и работает браузер. Непосредственно на прямую в браузере запускается либо JS, либо WASM, другого не дано - 100%. А сам WASM вполне успешно используется на довольно крупных и успешных проектах: Figma, AutoCAD и т.д.
@@ashimov1970 тут дело не в самом C# или Rust, дело именно в реализации. + на одном из открытых источников встретил такое вот предложение о Blazor: "Файлы, загруженные браузером, имеют большой размер, что влияет на увеличение нагрузки сети и на время загрузки в целом, так как приложения работают на стороне клиента", это может объяснить долгую загрузку в начале у автора.
Немного некорректен тест на перебор массива. Вы в Rust-коде используете строго типизированный массив, а в JS используете Array. У строго типизированных массивов с фиксированной длиной производительность гораздо выше, так как они хранятся в стеке (их размер известен в момент компиляции), а вот для массивы, длина которых не известна в момент компиляции, хранятся в куче. Доступ в стек наша программа имеет напрямую, а вот в кучу она может обращаться только лишь через операционную систему, что добавляет задержку.
Логичнее было бы либо использовать в Rust-коде вектор, либо в JS тоже использовать строго типизированный массив Int32Array.
Спасибо большое! Очень познавательно!
Всегда пожалуйста) Рад, что вам было полезно)
Было очень интересно, спасибо за видео
Очень рад, что вам понравилось )
спасибо за такой крутой урок! сделайте пожалуйста урок по работе с канвасом через webassembly (как сейчас работает фигма)! будет очень интересно узнать
Спасибо, информативно. Webasembly, например, используется в mitek SDK
И вам спасибо )
Я думаю, что в первом примере компилятор оптимизирует простой цикл до b = arg * 2;
Figma на нем работает, если не ошибаюсь. На чистом JS такого не сделать, в принципе. Так что думаю фишка WA далеко не в скорости перебора цикла или операций сложения.Но canvas, вышедший в html5, в принципе закрывает большинство потребностей делая WA не сильно востребованным.
Я пытался показать на примере простых операций преимущество в скорости. Но ведь высокая производительность нужна не только при работе с изображениями, + можно WA использовать и для работы с canvas, просто далеко не везде нужна такая оптимизация
Тут выиграл Rust а не WASM. Тот же Blazor (C# + WASM) намного проигрывает в скорости JS фреймворкам.
Боюсь, что вы не правы.
Объясняю:
Данное приложение никоим образом не может взаимодействовать с Rust напрямую. Rust лишь компилируется в Wasm, который и работает в браузере, а мы, в свою очередь, лишь используем определённый интерфейс для взаимодействия с Wasm в приложении.
Выполнение кода Wasm (если он скомпилирован из другого языка) может зависеть лишь от компилятора, а если быть точнее - от того, насколько правильно был скомпилирован код. То есть - возможно проблема в blazor, с ним я непосредственно не знаком.
А почему именно фреймворки, в чем они именно быстрее и какие именно фреймворки ?
@@AndreyChuprin0101 глянь видео "Blazor wasm VS Angular. Катастрофический результат сравнения"
@@ashimov1970 Просмотрел и почитал о Blazor немного - проблема именно в нем, он лишь использует обертку WASM, а потом как-то соединяет среду выполнения .NET и браузера, я не сильно углублялся в механизм за счет которого это все дело работает, но суть в том, что код C# не выполняется прямо в баузере в привычном понимании. А если использовать wasm-pack - он компилирует код Rust в WASM, с которым уже и работает браузер. Непосредственно на прямую в браузере запускается либо JS, либо WASM, другого не дано - 100%. А сам WASM вполне успешно используется на довольно крупных и успешных проектах: Figma, AutoCAD и т.д.
@@ashimov1970 тут дело не в самом C# или Rust, дело именно в реализации. + на одном из открытых источников встретил такое вот предложение о Blazor: "Файлы, загруженные браузером, имеют большой размер, что влияет на увеличение нагрузки сети и на время загрузки в целом, так как приложения работают на стороне клиента", это может объяснить долгую загрузку в начале у автора.
@@ashimov1970 Но в любом случае - спасибо вам. Я впервые увидел такой способ реализации, мб где-то будет для меня полезным).
0 мс, цикл проходит моментально? чудеса да и только...
Нет, не моментально) Есть величины меньше мс)