В ЧжихуКак думать о технологии WebAssembly», видно, что существует много недоразумений по поводу треугольной связи между браузерами, WASM и JS. Итак, как разработчик (бай) (сюэ) (цзя), позвольте мне попытаться исправить некоторые распространенные проблемы.
Полный текст заключения:Производительность WASM в принципе ограничена, и даже JS может конкурировать с Rust, скомпилированным в WASM. В сочетании с высокоинвазивной цепочкой инструментов он не очень подходит для всех, кто изучает интерфейс, но имеет большой потенциал для кросс-платформенного распространения нативных приложений..
WASM == Производительность на уровне сборки?
Это явно неправильно.Под сборкой в WASM подразумевается не настоящий ассемблерный код, а просто новый согласованный байт-код, который также требуетустный переводчикВ ходе выполнения. Такой интерпретатор определенно намного быстрее, чем интерпретатор JS, но, естественно, он не может достичь уровня настоящего машинного кода. Индикатор данных для справки: общая производительность JS после JIT составляет примерно 1/20 от машинного кода, в то время как WASM может работать до порядка 1/3 машинного кода (трудно сказать, в зависимости от сцены, только для справки).Эквивалентно тому, что даже если вы пишете на языках уровня C++ и Rust, на самом деле вы получаете производительность только на уровне Java и C#.. Это также объясняет, почему WASM не демонстрирует значительных преимуществ в производительности во всех сценариях приложений:Пока вы знаете, как заставить движок JS идти по счастливому пути, тогда в браузере JS осмелится конкурировать с Rust..
Классический случай сравнения производительности между WASM и JS — это сцена обучения белых разработчиков Mozilla и разработчиков V8. Весь процесс выглядит так:
- Mozilla Hacks опубликовала статью под названиемОптимизация производительности исходной карты с помощью Rust и WASMсообщение в блоге, будет
source-mapПроизводительность этого пакета JSВ пять раз лучше. - Разработчик ядра V8 Вячеслав Егоров ответилВероятно, вам не нужны Rust и WASM для оптимизации JS.запись в блоге, реализованная на чистом JSУдивительные оптимизации, которые быстрее, чем Rust.
- оригинальный авторскорость без магииНазвание обсуждается далее, и в Rust сделаны новые оптимизации производительности.
Так совпало, что этот спор состоялся два года назад.Сезон Белого альбома. У двух сторон была дуэль высокого уровня, как у Юкины и Томы, и знаменитая сцена была очень захватывающей. Напоследок Вячеслав привел сравнительную таблицу результатов после трех раундов трюков. Видно, что хотя Rust в итоге оказался быстрее, после того, как его довели до предела, JS не только не проиграл, но и выиграл раунд:
JS: Вы первый, кто начал оптимизацию производительности! Ты тот, кто ушел с моего пути без разрешения! Очевидно, вне досягаемости, но так близко, ты первый придумал этот метод пыток! Очевидно, это так, почему вы должны винить меня...? Вот так... каждый день, каждый день так быстро бегать перед глазами... и говорить, что это я во всем виновата... это жестоко...
Кроме того, Milo Yip провел множество тестов производительности трассировки лучей на разных языках (Shura Field), что также может подтвердить вывод о сравнении производительности между языком VM и машинным кодом. Без специальной оптимизации C++, Java и JS могут иметь три типичных уровня производительности соответственно:
C++/C#/F#/Java/JS/Lua/Python/Ruby тест рендеринга
Руби: Почему вы все такие опытные!
WASM быстрее, чем JS, поэтому его следует использовать для приложений с интенсивными вычислениями?
Это немного предвзято, WASM тожеCPUрасчет по. Для задач, которые могут быть сильно распараллелены, используйте WebGL для выполненияGPUРазгон, как правило, быстрее. например яНачало работы с практической обработкой изображений WebGLАлгоритм обработки изображений, описанный в этой статье, может быть в десятки раз быстрее, чем обход пикселей Canvas в цикле for в JS. И такую тяжелую работу с двухслойным циклом for можно переписать в несколько раз быстрее с текущим WASM, что очень хорошо. Что касается производительности вычислений искусственного интеллекта в браузере, то сообщество пришло к выводу, что WebGL и WebMetal имеют самые высокие уровни производительности, за которыми следует WASM. Посмотреть здесь:Обзоры ИИ в браузере
Однако ускорение WebGL имеет проблемы с точностью. Например, фронтальная библиотека масштабирования изображений Pica, в ее ядре используется алгоритм выборки Ланцоша. Я реализовал этот алгоритм в шейдере WebGL, это не так сложно, и в первые дни Pica использовала необязательные оптимизации WebGL, но теперь он ломает WASM. Причина такого решения в том, чтоWASM может гарантировать, что результаты расчета при тех же параметрах согласуются с JS, но WebGL не может.. Смотрите соответствующее обсуждение здесь:Issue #114 · nodeca/pica
Поэтому для ресурсоемких задач WASM — не единственный спаситель фронтенда, но дает каждому дополнительный выбор, чтобы сбалансировать производительность, стоимость разработки и эффект. По моему личному впечатлению, существует не так много сценариев, в которых интерфейсу требуются вычислительные мощности за пределами рендеринга графики, такие как шифрование, сжатие и майнинг, которые едва ли можно отнести к высокочастотным жестким потребностям. Что касается приложений ИИ, которые могут быть очень важны в будущем, то в долгосрочной перспективе я по-прежнему оптимистичен в отношении WebGPU, стандарта следующего поколения, который может лучше использовать потенциал графических процессоров.Конечно, WASM уже является хорошим вариантом.
WebGL: Это был я, я пришел первым, очевидно, я пришел первым... 3D, обработка изображений или глубокое обучение...
Можно ли повысить производительность, просто встроив функции WASM в JS?
Поскольку WASM работает быстро, стоит ли мне просто вставлять JS?const add (a, b) => a + bМожно ли заменить такой код на WASM, скомпилированный на C, для эффективного повышения производительности?
Это не обязательно так, потому что движки JS в современных браузерах стандартно поставляются с одной вещью, а именно:JIT. Проще говоря, вышеaddЕсли функция всегда вычисляет целочисленное сложение, то движок JS автоматически скомпилирует вычисление.int a + int bВместо оригинальной JS-функции производительность частого вызова этой функции будет значительно улучшена, что является секретом так называемой JIT-компиляции Just-in-time.
Так что не думайте о том, чтобы вручную полагаться на WASM для встраивания C, если вы считаете, что JS работает медленно.На самом деле, современные JS-движки постоянно помогают вам «автоматически конвертировать JS в C»! Если вы можете переписать функцию JS в эквивалент C, то я думаю, что если функция извлекается отдельно, JIT движка JS, вероятно, достигнет аналогичной производительности. Это должно быть уверенность в том, что разработчики V8 осмелятся использовать JS и Rust для выравнивания.
как будтоЗвонки между JS и WASM наконец стали быстрееВ этой статье Лин Кларк блестяще обсуждает весь процесс оптимизации, который в конечном итоге делает вызов функции между JS и WASM быстрее, чемне встроенныйВызовы между функциями JS выполняются быстрее. Однако в этой статье не упоминается, как это сравнивается с вызовами функций JS, которые встроены в JIT.
Вот побочный вопрос, Mozilla часто рекламирует внедрённые ею сверхсущественные оптимизации, и многие из них могут быть связаны с явными проблемами дизайна ранее (честно говоря, сами мы не такие). Как прошлогодний Firefox 70 на MacЗначительная оптимизация энергосбережения, каков его источник? Грубо говоря, предыдущий Firefox на Mac оказалсяПолное количество пикселей окна обновляется каждый кадр! Конечно, в этих статьях довольно много сухого материала.Настоятельно рекомендуется прочитать исходный текст после того, как заложишь хорошую основу.По крайней мере, это большой мир, и он часто может вдохновить на разработку архитектуры программного обеспечения.
Если последующий WASM поддерживает GC, ситуация со встроенной интермодуляцией, вероятно, будет более сложной. Например, недавно я пытался вручную синхронизировать большие объекты между Dart во Flutter и Java в Android, надеясь «встроить некоторые возможности платформы Android в систему Flutter», но это привело к созданию большого количества утомительного и низкопроизводительного связующего кода, который необходимо Асинхронные сообщения используются для глубокого копирования, а управляемость очень низкая. Хотя WASM еще не имеет GC, после его добавления у меня есть основания подозревать, что он столкнется с аналогичными проблемами с управлением жизненным циклом объекта между ним и JS. Просто эта проблема в основном касается сотрудников Mozilla и Google, а не нас.
Неважно, какие параметры передаются. Поскольку функции больше нет, стоит настроить. Указатели, которые нельзя передать, больше не нужны. Поскольку объекта больше нет, его стоит любить.
Так же легко настроить WASM в JS, как настроить C в Python?
Этот вопрос может иметь значение только в том случае, если это действительно сделано. Как эти вещи, которые я пробовал недавно:
- Вызов C ++ в классе Java Android
- Вызов C в Flutter's Dart
- Вызов C во встроенном движке JS, таком как QuickJS
Все они могут сделать одно: создать новый собственный объект в движке и использовать его в качествепередача по ссылкеПередавайте вызовы функций C/C++ напрямую и используйте сборщик мусора движка для управления временем существования объекта. Этот метод обычно называется FFI (интерфейс внешних функций), который может встраивать собственный код в среду выполнения языка. Но если есть две разные среды выполнения, все не так просто. Например, проект привязки QuickJS к JavaQuack, вам нужно выполнить процесс сортировки (сериализация и десериализация, например JSON) в объектах JS и Java, и вы не можете передавать ссылки случайно.
Каково это для WASM? По сути, линейное пространство памяти WASM можно читать и записывать с помощью JS без проблем с глубоким копированием. Однако в WASM есть только типы данных, такие как int и float, а не даже строка, поэтому для немного более сложных объектов сложно написать соответствующие структуры JS и WASM вручную. Теперь всю грязную работу делают колеса типа wasm-bindgen. Но в конце концов, этот процесс не встраивает функции C/C++ напрямую в JS Runtime, что сильно отличается от традиционного FFI, скомпилированного в машинный код.
Что касается объектов JS, которые не могут быть выражены в объекте памяти WASM, вы столкнетесь сдвойное счастьеэта проблема. Например, если вам сейчас нужно часто манипулировать объектами JS с помощью WASM, это почти наверняка повлияет на производительность. Типичной ямой в этом отношении является OpenGL-приложение, основанное на портировании WASM. как в С++glTexImage2Dфункции, после компиляции в WASM вам нужно сначала перейти от WASM к клеевому слою JS, а затем настроить его в JSgl.texImage2DНаконец, такой WebGL API может быть вызван к собственному графическому API через привязку C++. Таким образом, он изменился с одного слоя клея на два слоя.Не говоря уже о производительности по сравнению с нативным C++, можно ли его сравнить с написанием непосредственно на JS?
Конечно, в Mozilla тоже знают об этой проблеме, поэтому пытаются лучше открыть Web IDL (то есть привязку нативного API браузера) к WASM, а в процессе предлагаютWASM Interface TypesКонцепция: Поскольку WASM уже является средним уровнем байт-кода, просто дайте ему согласие.Унифицировать спецификацию IR для всех типов среды выполнения языков программирования.Бар! Тем не менее, эта спецификация по-прежнему надеется в основном полагаться на протоколизированную и структурированную глубокую копию для решения проблемы, только в будущем.anyrefТипы передаются по ссылке.anyrefНекоторые из них похожи на файловые дескрипторы в Unix, поэтому я не буду их здесь подробно описывать.
Поэтому в будущем в WASM могут появиться возможности доступа к DOM, но пока это все-таки торт. Не говорите, что некоторые расширения, такие как WebGL, уже явные.Не поддерживается Web IDL, даже если основные веб-стандарты будут открыты для WASM и популяризированы среди обычных пользователей, в 2020 году это кажется довольно далеким.
Браузер: Почему это происходит... Впервые появился высокопроизводительный язык сценариев, совместимый с передовыми родными языками. Две радости совпали. И эти две радости принесли больше радости. То, что я получил, должно было быть счастливым временем, как сон... Но почему оно стало таким...
Будет ли интерфейсный фреймворк рано или поздно переписан с использованием WASM?
Я думаю, что это сложно, или ROI этого вопроса может быть недостаточно. Поскольку для основных интерфейсных приложений все они требуют больших операций ввода-вывода, а не вычислений, в настоящее время повышенная вычислительная мощность WASM вряд ли станет узким местом, но это увеличит стоимость обслуживания многих проектов.
Одним из аргументов в пользу этого является то, что GoogleВведение в JIT-less V8. Пиковая производительность V8 снизилась до менее чем одной десятой от исходного уровня при отключении JIT (см.QuickJS Benchmark), но это почти не влияет на производительность легкого приложения, такого как YouTube.По стандарту Speedometer, который имитирует большую нагрузку веб-приложения, его текущий балл также составляет около 60% от исходного, только в задаче типа упаковки Webpack. Считаете ли вы, что после перехода на WASM, даже если пиковая вычислительная мощность удвоится по сравнению с сегодняшним днем, он может продемонстрировать разрушительный прорыв в управляемых событиями сценариях с интенсивным вводом-выводом графического интерфейса? Можно ли убедить авторов фреймворка полностью отказаться от существующей кодовой базы JS и полностью переписать фреймворк на другом языке? Более того, в долгосрочной перспективе WASM приходится полагаться на большое количество связывающего JS-кода и полифилов, которые достаточно велики, чтобы повлиять на производительность первого экрана.
WASM переписывает структуру пользовательского интерфейса с мейнстримом, что означает, что передняя часть должна сильно полагаться на совершенно другой стек языковых технологий.Вы говорите, что приложения Node должны быть переписаны на Java, потому что JVM быстрее, чем V8?? Я думаю, что политкорректность во внешнем кругу, очевидно, наоборот...
Даже если я мертв и загнан в гроб, я все еще в могиле, крича этой гнилой голосовой связкой: JS — это круто! ! ! (запрещено)
WASM относится к внешней экосистеме?
Я не согласен с этим. Знать,Приложение WASM, его набор инструментов для компиляции и экология библиотеки зависимостей в основном вообще не используют JS..
В 2018 году я пытался скомпилировать ffmpeg в WASM, весь процесс почти не имеет ничего общего с JS, основное внимание уделяется сборке среды компиляции Docker и внесению магических изменений в Makefile. На моем уровне в то время весь процесс был очень запутанным для меня.
Позже, в процессе подбрасывания встроенного линукса и андроида, кстати разобрался.набор инструментовКонцепция чего-либо. Нативное приложение должно быть скомпилировано, собрано и слинковано, чтобы стать исполняемым файлом. Например, моя машина для разработки — это Mac, тогда типичные наборы инструментов, установленные в macOS, выглядят следующим образом:
- Набор инструментов для macOS — это набор clang, скомпилированный в двоичный формат macOS.
- Набор инструментов, ориентированный на Android, представляет собой набор aarch64-linux-android-gcc, скомпилированный в двоичный формат ARM (вы можете найти его в NDK).
- Набор инструментов для PSP представляет собой набор mips-gcc, скомпилированный в двоичный формат MIPS (название может быть неверным).
- Набор инструментов для WASM представляет собой набор Emscripten для формата байт-кода WASM.
Последние три скомпилированы для других платформ, поэтому они называютсяперекрестная компиляция.
Набор цепочек инструментов, поддерживающих кросс-компиляцию, будет поставляться с некоторыми библиотеками для поддержки целевой платформы, такими как include<GLES2/gl2.h>После этого вы звонитеglTexImage2DAPI предоставляется в динамической библиотеке. Благодаря динамической библиотеке этот API может стабильно работать на таких платформах, как x86/ARM/MIPS/WASM (например, на Android.soФормат).Например, Emscripten предоставляет набор динамических библиотек для платформы WASM, скомпилированных в формат JS.. Но он может только гарантировать, что эти API можно использовать, а производительность — это другое дело. Это также вызывает много вопросов о сексуальных узких местах при портировании WebGL.Предложения по оптимизации.
Итак, вот оно снова,Библиотеки зависимости и вся цепочка инструментов, необходимая для компиляции приложений WASM, практически не имеют ничего общего с JS. JS похож на машинный код, это просто формат вывода, скомпилированный другими наборами инструментов. Разработчику JS все это может показаться довольно навязчивым. Но с точки зрения нативного разработчика приложений все это нормально.
Приходи и не уходи неприлично. WASM может ввести другие языки, но не может ли JS уйти? В дополнение к ревизионистской линии Flutter, Static TypeScript и QuickJS, которые я подробно представил, являются обратным результатом сторон Dongma, которые верят в JS:
- Поскольку TypeScript продолжает набирать популярность, будет ли среда выполнения, которая непосредственно запускает TypeScript?
- Render React на встроенный ЖК-экран
Сказав так много, каков применимый сценарий WASM? В настоящее время активно продвигаемые сообществом WASM предложения, такие как WASI, многопоточность и GC, на самом деле не имеют отношения к экосистеме JS, но удобныПеренос более сложных нативных приложений непосредственно в Интернеттехнические нужды. Все сказано и сделано, разве вы еще не видели? Разве это не типичная дощатая дорога Минсю в стиле Сюэкай, темный Чэньцан (смеется)
Наконец, подводя итог, можно сказать, что персонажи JS и WASM примерно такие:
- ДС: Я пришел первым,Где браузер, где мой дом. Хотя некоторым людям не нравится мой темперамент, я черный и прямой сценарий, куда бы я ни пошел. За мной гонятся какие-то движки, но я всегда в первую очередь верный пес браузера.
- WASM: Я Цветок Высокого Хребта. Все внутри и вне браузера приветствуют меня, и любой может скомпилировать для меня, так что каждый может использовать мой двоичный формат. Хотя я очень хочу быть с JS и браузерами навсегда, но я хочу быть кроссплатформенным в будущемПока я усердно работаю, я могу быть счастлив вечно.
WASM: Ах... если бы JS были строго типизированными мальчиками.
Как вы думаете, кто вам больше нравится, Донгма (JS), который пришел первым, или Юкина (WASM) из Као Линчжихуа? Вспомните некоторых белых ученых, которые весь день кричали, что я хочу всего, двойное счастье — это не то, что обычные люди могут себе позволить.
Вообще говоря, партия Донгма имеет самую большую базу среди всей группы белых ученых (программистов), но хардкорные игроки часто представляют собой партию снежной тарелки. Что касается меня... Посмотрите на название цветка в моем профиле?
На последнем фото Донгма и Юкина оба хороши собой!
постскриптум
WASM, безусловно, является революционной технологией, представляющей новое направление кроссплатформенности, особенно для разработчиков нативных приложений с огромной коммерческой ценностью. Но на самом деле это виртуальная машина с байт-кодом, встроенная в браузер для внешнего интерфейса, а не панацея от всех проблем с производительностью. В настоящее время в интернете много хвалебных отзывов о нем, на мой взгляд, он несколько переоценен. Поэтому не рекомендуется слепо следовать тренду или начинать сБай Сюэ,О нетИнформатикаДавайте начнем с основы технологии, чтобы определить применимые сценарии и ценность технологии.
Все изображения в этой статье взяты из высокопроизводительных интерфейсных приложений, реализованных на чистом JS.Проект ПС. Часть Bai Xue предназначена исключительно для развлечения, пожалуйста, не переоценивайте ее (например, почему логотип JS окрашен в желтый цвет снежной капусты, а логотип WASM — в фиолетовый Dongma и т. д.). Мой уровень ограничен, и вы можете продолжить обмен техническими взглядами на эту статью, и я надеюсь, что вы обратите внимание на мой "Случайные мысли во внешнем интерфейсе"Эта бесплатная техническая колонка~