Design: Будет ли компилятор JS -> WASM?

Браузеры по-прежнему будут иметь встроенную виртуальную машину JavaScript вместе с wasm. Нет причин компилировать JS в wasm, потому что вам также придется включить целую виртуальную машину javascript. В результате код будет огромным и медленнее, чем изначально предоставленная виртуальная машина JS.

Существует пост MVP для добавления таких вещей, как добавление доступа к сборщику мусора из кода wasm, чтобы можно было реализовать языки сценариев для wasm.

JS → wasm будет иметь смысл только в том случае, если wasm поддерживает сборку мусора и, скорее всего, JIT-компиляцию, до которой еще далеко. По сути, это было бы эквивалентно реализации движка JS в wasm! Я недавно упомянул об этом, и @BrendanEich обвинил меня в том, что меня перехватил horse_js.

Чтобы было ясно, цель wasm не в замене JavaScript, а в его дополнении. Поэтому на данный момент не является целью поддерживать JS → wasm, но функции, которые мы хотим реализовать, сделают это возможным. Однако я не уверен, что это будет так полезно с точки зрения разработчика. Вы можете немного уменьшить размер, но не более того. С точки зрения браузера может быть интересно реализовать JS-движок в wasm с точки зрения чистой безопасности.

@jfbastien Я тебя опередил на 2 секунды;)

Но твой ответ лучше. Я в восторге от GC и JIT в wasm. Мне нравится создавать свои собственные языки и запускать их в Интернете.

А как насчет поддержки таких вариантов, как asm.js или TypeScript / ES7? Эти
разновидности Javascript обещают некоторый уровень гарантий типов.

Я бы предположил, что потребность в JIT будет меньше, но GC все еще очень
необходимо для этих языков. Будет ли иметь {типизированный аромат JS} -> WASM make
это возможно?

W: http://bguiz.com

24 июня 2015 года в 09:44 Тим Касвелл [email protected] написал:

@jfbastien https://github.com/jfbastien ты победил меня на 2 секунды: P

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456.

Да, переводчик asm.js -> wasm имеет высокий приоритет, и Люк уже сделал это.
поработайте над компрессором, который может послужить хорошей отправной точкой.

В среду, 24 июня 2015 г., в 01:59, Брендан Гретц [email protected]
написал:

А как насчет поддержки таких вариантов, как asm.js или TypeScript / ES7? Эти
разновидности Javascript обещают некоторый уровень гарантий типов.

Я бы предположил, что потребность в JIT будет меньше, но GC все еще очень
необходимо для этих языков. Будет ли иметь {типизированный аромат JS} -> WASM make
это возможно?

W: http://bguiz.com

24 июня 2015 года в 09:44 Тим Касвелл [email protected] написал:

@jfbastien https://github.com/jfbastien ты победил меня на 2 секунды: P

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789.

Мы поговорили с командой TypeScript об этой возможности, и они проявили интерес, но похоже, что в настоящее время наблюдается прогресс в добавлении типизированных объектов в JS.

@bguiz : движок JS - это движок wasm, и он будет продолжать поддерживать развивающийся стандартный язык JS. Не беспокойтесь об этом (я не был уверен, думали ли вы, что это может исчезнуть. Ни в каком будущем, которое я могу предвидеть). OTOH, как отмечают другие, wasm нужно время, чтобы развить GC, поддержку JIT и другие функции динамического языка, чтобы стать первоклассной целью для JS. Я сомневаюсь, что даже когда он будет развивать эти вещи, движки JS / wasm откажутся от своего синтаксиса и встроенных модулей JS в пользу загруженных виртуальных машин JS-in-wasm. Мы увидим!

/быть

Мы также планируем добавить в Emscripten переводчик asm.js в WebAssembly.

Что касается обычного JS, я думаю, что другие ответили на вопрос выше.

Весь смысл JS прост в кодировании и может делать удивительные вещи: dhteumeuleu или codepen.io/ge1doot, но вы можете видеть исходный код и его легко взломать.

«wasm» - это только способ продать больше игр и других приложений для Google, Apple и других. Единственная «эволюция» заключается в том, что вы сможете лучше контролировать вас с помощью «без установки», прямо с сервера старшего брата ... Я просто удивлен, что они еще не боятся съесть друг друга ...

С помощью анализа кода или аннотаций кода можно скомпилировать ECMAScript в WebAssembly. Это не кажется приоритетом для команды WebAssembly, но звучит как отличная идея для независимых усилий.

Я только начал экспериментировать с игрушечным языком программирования, который может оказаться актуальным: https://github.com/evanw/thinscript. Он использует синтаксис в стиле TypeScript и компилируется в WebAssembly. Я подумал, что должен упомянуть об этом, потому что это может быть интересный пример. Также я был приятно удивлен тем, насколько легко было сгенерировать WebAssembly. Всем отличной работы!

Я бы предостерегал людей от использования очень тонких оберток поверх wasm в целом. В качестве одного примера, пролистывая код thinscript, я вижу, что есть оператор while который понижен до loop { if (!condition) break; } , что будет менее эффективно, чем if (condition) loop { ...; br_if condition } на нескольких машинах wasm.

Для меня то, что делает wasm больше, чем просто повторно нагретый JS, - это возможность другой философии: поскольку wasm является целью компилятора, компиляторы могут выполнять оптимизацию перед отправкой кода клиентам, чтобы мы могли упростить клиентские виртуальные машины и Быстрее. Однако, если тонкие оболочки вокруг wasm станут популярными, есть риск того, что реализации на стороне клиента в конечном итоге станут более громоздкими и сложными, чтобы выполнять оптимизацию, которая не выполняется.

Да, я согласен. Что мне больше всего нравится в WebAssembly, так это его простота. Я планирую добавить оптимизацию компилятора и провести тесты, когда язык станет более полным. Я ожидаю, например, что встраивание станет одним из самых больших достижений, и не ожидал, что WebAssembly сделает это за меня. Я также планирую поэкспериментировать с целью машинного кода и буду использовать одинаковые оптимизации для обеих целей.

Звучит очень круто! Мне будет интересно посмотреть, к чему это приведет.

Я представляю, что JS-> WASM более привлекателен для серверов, чем для клиентов. В качестве очень высокого обзора архитектуры, которую я имею в виду ...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

В этой концепции было бы очень желательно четкое отображение WASM на LLVM IR для сборки мусора . Переход от двойников IEEE к целым числам может быть осуществлен как проход LLVM. Понятие отдельных JIT для горячего и горячего кода может быть реализовано в терминах диспетчеров проходов LLVM.

Просто некоторые мысли, пожалуйста, удалите это, если оно ложное!

Совместимость между средами - серьезная проблема в экосистеме JS. Babel пытается решить эту проблему, перейдя к более адаптированной версии ES, и я думаю, мы все можем сказать, что она довольно успешна.

Однако здесь все еще есть проблема. Например, если вы переносите свой код ES 2016 на ES5 для совместимости, и ваш код запускается в среде с (частичной или полной) поддержкой ES 2016, вы упустите преимущества поддержки ES 2016 в своей среде. .

Если все переносят свой код на ES5, то в чем вообще преимущество поддержки ES 2016 в среде?

Новый проект под названием «babel-preset-env» пытается решить эту проблему, ориентируясь на среды по их версиям. Идея заключается в том, что (1) вы просите его настроить таргетинг на определенные версии или «последние X-версии» браузеров, (2) он определяет наименьший общий знаменатель функций и (3) разрешает только необходимые транспиляции. Это помогает, но, к сожалению, не может решить проблему.

У нас все еще есть риск того, что крупный поставщик не будет вести себя и вызовет те же проблемы, которые Microsoft создавала с Internet Explorer в течение многих лет. Вся экосистема находится в руках нескольких поставщиков, которые решают, что и когда реализовать. Это не бесплатно и не открыто.

Единственное решение - это новая цель компиляции для JavaScript, которая является производительной и требует гораздо меньшего обслуживания (надеюсь, никакого), чем JS-движок. Когда среды (браузеры, Node.js и т. Д.) Начинают поддерживать такую ​​цель, реализация новых функций ES должна стать обязанностью компиляторов, а не поставщиков движков.

JS -> WASM было бы интересно защитить интеллектуальную собственность путем обфускации кода, когда дело доходит до локальной установки, скажем, приложений Electron на серверах клиентов. В это трудно поверить, но это правда, что в Германии есть много небольших организаций с очень слабым подключением к Интернету или без него, что требует локальной установки, но предоставление им всего вашего кода в виде открытого текста может быть пугающим для компаний-разработчиков программного обеспечения.

@ Simran-B В соответствии с принципом дизайна Wasm поддерживает знакомый текстовый формат. Примечательно, что он имеет структурированный дизайн потока управления для быстрого анализа и оптимизирован для одноразовых определений, используемых в порядке стека, поэтому оптимизирован для читаемых выражений. Таким образом, это не цель «обфускации кода», но разработчики могут использовать свои собственные «обфускации кода» поверх нее, но должны понимать, что это, как ожидается, приведет к снижению эффективности кодирования и производительности.

Привет всем, я недавно открыл для себя WebAssembly, но, думая о компиляторе JS -> wasm, я представил себе что-то вроде компиляции Angular2 Ahead-of-Time, jsut намного более оптимизированной (я думаю, что машинный код вместо javascript) ... Будет ли это когда-нибудь возможно? Стоит ли оно того?

РЕДАКТИРОВАТЬ
Я также думаю, будет ли когда-нибудь возможность для браузера отправить клиенту флаг о том, что он поддерживает wasm, и тогда мы сможем обслуживать предварительно скомпилированное приложение вместо файла javascript?

Ричард

@ Richard87 вы можете рассматривать веб-сборку как платформенно-независимый набор инструкций со своими собственными специализированными соглашениями о кодировании и вызовах. Ничто не говорит о том, что вы не можете описать подмножество javascript, которое было бы очень легко транспилировать для работы в мире этих вещей webassembly, но обеспечить это, вероятно, будет сложно. Набор функций и область реализации в javascript постоянно растут, и адаптация существующих библиотек и фреймворков для работы в этом подмножестве, вероятно, будет сложной, особенно с учетом текущего отсутствия сборки мусора в веб-сборке, и вы по существу потеряете преимущества существующего javascript. код.

С добавлением примитивов сборки мусора в веб-сборку подмножество javascript, которое можно было бы транспилировать без написания большой виртуальной машины, расширилось бы, но все же, на мой взгляд, это не было бы оптимальным по сравнению с простым переносом из более подходящего язык, поскольку ваши накладные расходы в javascript будут лишь незначительно меньше, важные накладные расходы в веб-приложениях (сети!) будут расширяться, а преимущества, которые вы хотели бы получить от использования javascript в первую очередь, по-прежнему будут недосягаемы, помимо того, чтобы сказать, что он использует что-то похожее на «javascript» (на самом деле это та же лодка, в которой находится Unity с UnityScript, за исключением того, что они несколько адаптировали ее для лучшей интеграции со своими подсистемами и соглашениями о вызовах в целом, помимо других прихотей).

Я думаю, что для некоторых из нас, кто интересуется браузером и Webgl, чрезвычайно важно быть быстрее в играх. Я намереваюсь сделать игру коммерческого качества в webgl, но текущая технология производит столько мусора, что кадры пропускаются.
Браузерные игры с использованием игровых движков JS почти потерпели неудачу, и Unity стала популярной. Я думаю, что C ++ => Wasm - это неуместное преимущество для таких крупных разработчиков фреймворков, как Unity, которые могут кросс-компилировать свой код в WASM.
Но как насчет людей, которые пишут JS вручную, используя Three JS или Babylon? .. Отсутствие JS / Asm.js => инструментария Wasm означало бы, что большое приложение на Js будет мертвым, и люди будут использовать C ++ и бэкенды генерации кода для создания Wasm. Точнее в играх и тому подобном.
Отсутствие бэкэнда JS => Wasm несправедливо по отношению к разработчикам JS. Кроме того, EMCC выделяет большую кучу при запуске, и из-за этого скорость очевидна, но разработчики Js, которые пишут хороший код js, все еще не могут достичь такой высокой производительности из-за сложности написания такого кода. Должен быть какой-то механизм для повторного использования большинства вещей и возможность вызывать gc раньше или по желанию. Пропуск кадров при запуске GC приводит к тому, что Webgl пропускает кадры, это большая проблема, которую необходимо решить. Должен быть какой-то механизм для ручной настройки кода JS лучше, чем генераторы кода. как и рукописная сборка, по-прежнему производит гораздо меньший и хорошо согласованный код. Это должно быть возможно в веб-сборке.

@metacritical C ++ может компилироваться в WASM, потому что многие люди вкладывают в этот процесс много работы. То же самое может произойти и с JavaScript, но, насколько мне известно, в настоящее время никто не пытается этого сделать. Для этого нет особых причин: производительность не изменится.

Проблема вашего движка - это сборка мусора. Эта проблема не исчезнет, ​​если вы создадите алгоритм сборки мусора, который использует линейную память и код WASM ... в конечном итоге вам придется остановить программу, чтобы увидеть, какие объекты все еще живы, и удалить те, которые нет. Решение состоит в том, чтобы не создавать мусорные объекты, что исключает необходимость когда-либо запускать сборщик мусора. Для этого вам не нужен WASM, вам нужно переделать свой движок.

Ультра-чистый Javascript, который повторно использует массивы и производит мало мусора, писать чрезвычайно сложно. Также я думаю, что Plain Js не может быть скомпилирован в WASM. Asm.js или Typescript будет легче скомпилировать в WASM из-за наличия в них аннотаций типов или типов соответственно.

@metacritical Сложно, но возможно. Даже в механизмах C ++ большая часть кода связана с управлением жизненным циклом объекта. Хотя это и нетрадиционно, нет причин, по которым вы не можете сделать то же самое в JavaScript.

Обычный JS _ можно_ скомпилировать в WASM, но компилятору придется добавить много вспомогательного кода, чтобы задействовать такие высокоуровневые функции JavaScript, как сборка мусора, отражение, свойства и т. Д. По сути, все, что вы получаете бесплатно, благодаря встроенному в браузер движку JS. TypeScript мало помогает.

Для сравнения, ASM.JS легко преобразовать в WASM. Строгий набор функций JS, разрешенных ASM.JS, также на 100% покрывается WASM. Если бы на ASM.JS был написан большой объем кода, это стоило бы усилий, но, насколько мне известно, все основные файлы ASM.JS создаются из исходного кода C ++, который уже может напрямую ориентироваться на WASM.

Для сравнения, ASM.JS легко преобразовать в WASM.

Правильный, и на самом деле основной способ компиляции C ++ в wasm сегодня - сначала скомпилировать его в asm.js, а затем скомпилировать этот asm.js в wasm с помощью asm2wasm Binaryen .

@kripken Глядя на спецификации asm.js, кажется, что легко написать рукописный asm.js, что означает, что для js-программистов еще не все потеряно, мы все еще можем получить двоичные файлы WASM, используя вышеизложенное.

Разве эволюция JS, т.е. строго типизированного языка, не могла бы сделать его хорошим кандидатом для JS -> WASM?
Я думаю, что у TC39 есть предложение для типизированного объекта. Возможно, это станет возможным благодаря другим функциям.

@ aruns07 Чем меньше функций JavaScript вы разрешите использовать, тем проще будет скомпилировать в WASM, и тем больше вероятность, что люди не захотят жить с вашими ограничениями из-за несовместимости со своими любимыми библиотеками.

@Kardax @ aruns07 Людям нравится удобство динамического языка. Сильные типы нужны нам иногда и не всегда.

jfbastien прокомментировал 24 июня 2015 г.
JS → wasm будет иметь смысл только в том случае, если wasm поддерживает сборку мусора и, скорее всего, JIT-компиляцию, до которой еще далеко. По сути, это было бы эквивалентно реализации движка JS в wasm!

По следующей ссылке:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
Консенсус WebAssembly и завершение предварительного просмотра в браузере

Теперь, спустя 2 года после вашего первого ответа, сегодня WebAssembly поддерживается основными веб-браузерами.
Так что реализация JS-движка в wasm не эквивалентна.
Преимущества js -> wasm - это не только поддержка GC, но также меньший размер кода и более быстрое выполнение, особенно в области разработки гибридных приложений, таких как Ionic2, который обычно создает файл JS размером около 10 МБ, что приводит к тому, что время загрузки приложения превышает 5 секунды (каждый разбор 2 МБ JS = 1 секунда)

@jfbastien Итак,

В рамках своей магистерской диссертации я пытаюсь написать Transpiler из подмножества JavaScript в WebAssembly. Сначала он будет ограничен TypeScript, но в будущем могут поддерживаться другие типизированные варианты, такие как Flow.

Однако цель состоит не в том, чтобы реализовать полный язык JavaScript, поскольку в этом случае я столкнусь с теми же проблемами, с которыми сегодня сталкиваются реализации JIT, и, следовательно, никакого ускорения ожидать нельзя (более точно, моя реализация будет в 100 раз медленнее! ). Это будет подмножество, как определено SoundScript.

Моя цель - позволить компилировать определенные части приложения в WebAssembly без необходимости, чтобы разработчик покидал знакомую среду разработки или использовал другой язык программирования. Следовательно, он будет больше предназначен для ускорения производительности важных частей приложения, а не как транспилятор общего назначения, который принимает любое существующее приложение JavaScript.

Мне очень любопытно, какими будут мои выводы, поскольку я вижу плюсы и минусы такого подхода. Дайте мне знать, если у вас есть какие-либо предложения.

@ Mohsen7s, мой ответ остается точным: версия WebAssembly MVP не поддерживает возможности GC и JIT, которые позволяют реализовать быструю виртуальную машину JavaScript. Интерпретатор вполне возможен, с умными уловками он может быть неплохим, но не настолько, как то, что делают нативные реализации.

Это неотъемлемо для нашего подхода «минимально жизнеспособный продукт»: сначала отправьте что-то, что работает для некоторых вариантов использования, а затем добавьте функцию для других вариантов использования. См. Следующую ветку для аналогичного обсуждения MVP и отсутствующих «будущих функций»: https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

Оставляя в стороне технические дискуссии о том, что можно и что нельзя реализовать в настоящее время, я удивлен, что JS -> WASM не является целью номер 1 как с философской, так и с маркетинговой точки зрения - я не понимаю, как вы когда-нибудь добьетесь участие разработчика до тех пор, пока это не произойдет. Если бы все эти front-end / back-end / full-stack разработчики, обладающие навыками JS, способными работать в любой рыночной вертикали, вместо этого хотели бы тратить свое время на изучение C ++, который используется в значительно меньшем подмножестве отраслей, то они уже сделали бы это. так что - знаю, говорю как один. Я не могу не чувствовать, что вся эта дискуссия является чем-то вроде эхо-камеры и что те, кто защищает отсутствие компилятора, найдут, что их время лучше потратить на разговоры с людьми на забое, спрашивая их, чего они на самом деле хотят.

@BossLevel

Оставляя в стороне технические дискуссии о том, что можно и что нельзя реализовать в настоящее время, я удивлен, что JS -> WASM не является целью номер 1 как с философской, так и с маркетинговой точки зрения - я не понимаю, как вы когда-нибудь добьетесь участие разработчика до тех пор, пока это не произойдет. Если бы все эти front-end / back-end / full-stack разработчики, обладающие навыками JS, способными работать в любой рыночной вертикали, вместо этого хотели бы тратить свое время на изучение C ++, который используется в значительно меньшем подмножестве отраслей, то они уже сделали бы это. так что - знаю, говорю как один.

Браузеры уже могут эффективно запускать JavaScript. Браузеры не могут выполнять предполагаемые варианты использования так же эффективно. В довершение всего, WebAssembly не имеет устремлений в отношении Интернета.

Это обсуждение, а также https://github.com/WebAssembly/design/issues/992#issuecomment -281735235 иллюстрируют разнообразие целей, которые преследуют разные люди. Все не ошиблись! MVP просто нужно расставить приоритеты, кто обслуживается первым.

Я не могу не чувствовать, что вся эта дискуссия является чем-то вроде эхо-камеры и что те, кто защищает отсутствие компилятора, найдут, что их время лучше потратить на разговоры с людьми на забое, спрашивая их, чего они на самом деле хотят.

Это был весь смысл создания группы сообщества W3C. Мы думаем, что это удалось, о чем мы слышали от многих заинтересованных разработчиков. Некоторых не интересует MVP, но интересуют будущие функции .

@jfbastien

Браузеры уже могут эффективно запускать JavaScript.

Ха, я пытался написать многопользовательскую HTML5-игру, способную работать с приличным FPS на среднем мобильном телефоне с 2008 года, но меня все еще нет! И, учитывая, что когда я заключаю контракт на оплату счетов, я очень хорошо вознагражден, я почти уверен, что отсутствие прогресса не связано с качеством моего кода.

Это был весь смысл создания группы сообщества W3C.

Снова ха - сколько вы знаете реальных разработчиков, которые присоединяются к группе сообщества? Разработчики, которые это делают, обычно являются евангелистами и т. Д., Которые хорошо осведомлены, да, но чувствуют меньше боли от реальных разработчиков.

И мне очень жаль, но я действительно не хочу никого принижать на этой странице / вовлеченной / в W3C. Как вы говорите, это дискуссия, и это моя точка зрения с передовой.

Приносим извинения за то, что вернулся к этому, как собака, беспокоящаяся о кость, но пока я был в отъезде, я придумал лучший способ выразить свою точку зрения. В следующем информационном бюллетене / мероприятии сообщества или любым другим способом получения обратной связи задайте этот вопрос веб-разработчикам (вашим клиентам):

Чтобы вывести производительность браузера на новый уровень, вам нужно будет выучить другой язык; это было бы приемлемо?

Потому что это, по сути, вопрос, на который (на мой взгляд, вредно) уже были даны ответы некоторыми на этой странице.

И напоследок (обещаю ;-)) @jfbastien , если:

В довершение всего, WebAssembly не имеет устремлений в отношении Интернета.

почему это называется «WebAssembly»?

@BossLevel Думаю, я понимаю, откуда вы. Я не могу говорить от имени людей, проводящих евангелизацию, но я понимаю, что разные евангелисты контактировали с традиционными «нативными» разработчиками, которые заинтересованы в WebAssembly. С вашей точки зрения, это может быть неочевидным, но как минимум я могу указать на интерес Unity как на признак «серьезных» разработчиков. Эти люди также публикуют сообщения на github под своими именами, но их принадлежность не всегда очевидна. Не мне говорить за них.

Ха, я пытался написать многопользовательскую HTML5-игру, способную работать с приличным FPS на среднем мобильном телефоне с 2008 года, но меня все еще нет! И, учитывая, что когда я заключаю контракт на оплату счетов, я очень хорошо вознагражден, я почти уверен, что отсутствие прогресса не связано с качеством моего кода.

Я не имел в виду, что писать быстрый JavaScript легко. Я хотел сказать: WebAssembly не упрощает оптимизацию JavaScript. Скорее, он позволяет браузерам использовать формат, который лучше подходит для обеспечения надежной производительности. Это также позволяет TC39 сосредоточиться на улучшении самого JavaScript, а не только JavaScript в качестве цели компиляции.

Снова ха - сколько вы знаете реальных разработчиков, которые присоединяются к группе сообщества? Разработчики, которые это делают, обычно являются евангелистами и т. Д., Которые хорошо осведомлены, да, но чувствуют меньше боли от реальных разработчиков.

И мне очень жаль, но я действительно не хочу никого принижать на этой странице / вовлеченной / в W3C. Как вы говорите, это дискуссия, и это моя точка зрения с передовой.

Ваша точка зрения действительно верна, и я думаю, что ясно, что с вашей точки зрения я говорю то, во что трудно поверить. Мы должны лучше сообщить об этом (или эй, может я ошибаюсь: wink :).

Чтобы вывести производительность браузера на новый уровень, вам нужно будет выучить другой язык; это было бы приемлемо?

Потому что это, по сути, вопрос, на который (на мой взгляд, вредно) уже были даны ответы некоторыми на этой странице.

Я понимаю ваше беспокойство, но надеюсь, что это не так. Опять же, я могу ошибаться. На мой взгляд, WebAssembly привлекает на эту платформу новых разработчиков, разработчиков, у которых был плохой опыт работы с Интернетом в прошлом или которые слышали ужасные истории. В свою очередь, это помогает разработчикам JavaScript, которые хотят использовать «традиционный» код (который некоторые называют «устаревшим»), использовать этот код: мы хотим, чтобы WebAssembly можно было легко использовать из JavaScript. Для этого нужно просто использовать npm (что ... не всегда легко!).

Я в некоторой степени уверен, что это произойдет из-за отзывов, которые мы видели в Twitter, Hacker News, Reddit и на различных конференциях. Опять же, может я ошибаюсь и слушаю эхо-камеры. Как минимум, у меня были очень многообещающие дискуссии на конференциях с людьми, владеющими C ++, а также JavaScript.

В то же время TC39 действительно пытается улучшить JavaScript. Я считаю, что это произошло в последние годы, особенно с ES6.

Но ваша точка зрения остается неизменной: возможно, разработчики захотят хорошо разбираться в JavaScript, а также в более «дружественных к WebAssembly» языках, таких как C ++ или Rust. Я не знаю, как все пойдет.

почему это называется «WebAssembly»?

Ха! Замечательный вопрос. У меня есть доклад под названием «WebAssembly: ни Web, ни Assembly». Придется огласить это публично, чтобы я мог выразить свое отношение к названию: grin:

Так что я буду держать тебя в руках.

Читаю здесь два желания:

1. Двоичное представление стандартного JavaScript для быстрой загрузки.
2. Что-то, чтобы преодолеть разрыв в производительности между скомпилированным в исходном коде C ++ и стандартным JavaScript.

Пункт 2 является предметом постоянных исследований и крупных инвестиций многих компаний. Если вы посмотрите на измерения производительности движков JavaScript за последние 15 лет, они тоже работают ... разрыв становится все меньше.

Насколько мне известно, пункт 1 никем не прорабатывается. Это чрезвычайно сложно, и становится все труднее, поскольку JavaScript продолжает развиваться быстрыми темпами. WebAssembly очень строгий и относительно несложный, и на его разработку ушли годы.

@jfbastien - большое спасибо за взвешенный и внимательный ответ :)

Итак, пара иллюстративных моментов в произвольном порядке:

1) Хороший пример, который я вижу из всего этого обсуждения и моего взгляда на направление, в котором вы должны двигаться, связан с NodeJS - JS API / интерфейс для серверной части C ++ - вы получаете простоту использования / знакомства и т. Д. с одной стороны, и скорость с другой.
2) Придерживаясь Node, еще в 2008 году, когда я отправился в свою личную одиссею ;-) Изначально я рассматривал как PHP, так и Java в качестве серверной части (я возвращался к разработке после десятилетия, проведенного на темной стороне управления ИТ. и продажи ;-)!) но я быстро отказался от них по той простой причине, что я хотел выучить только один язык, и выучить его хорошо! Это личная история, которую я знаю, но я сомневаюсь, что я единственный разработчик, который так думает, особенно те, кто работает на себя, а не на копейки компании, пока они изучают язык.
3) Я намеренно не гуглил числа, прежде чем высказывать свое следующее мнение (действительно, я не уверен, смогу ли я вообще), но готов поспорить, что использование ASM было низким. Я знаю, что был очень взволнован, когда увидел начальную демонстрацию, но, узнав, что компилятора не было, я сразу же отказался от нее. Попросить веб-разработчика, который является частью крупнейшего сообщества разработчиков на планете (JS) с огромным набором API-интерфейсов, библиотек, ресурсов, руководств, фреймворков и т. Д., Доступных в Интернете, отойти от этого, на мой взгляд, требует слишком многого, и не предоставляя им средств потенциально сделать этот первый шаг (т. е. компилятор), упускает очевидный трюк с вашей стороны. Я бы даже зашел так далеко, что поспорил, что разработка Shading langage (GLSL) выросла больше, чем ASM, теперь, когда вы можете: а) записать его прямо в отличные фреймворки, такие как Pixi.js и Three.js, и б) поиграть с ним. прямо на таких сайтах, как ShaderToy .
4) Игровая индустрия / игры в целом. Я могу сказать здесь по своему опыту: а) я писал (еще не выпущенные!) Игры в течение последних 9 лет и б) я работал в совете директоров TIGA (торговая ассоциация разработчиков игр в Великобритании) в течение 2 лет. Поверьте мне, я думаю, что количество разработчиков игр, которые хотели перейти в Интернет, вероятно, можно было бы сосчитать по пальцам одной руки - разработчики игр уже работают в той индустрии, которую они любят, и, несмотря на это, даже получают много заработной платы / работают долгие часы, так что эти не должны быть целевой аудиторией WA. Да, их работодатели всегда ищут новые среды для переноса своих игр, но давайте не будем обманывать самих себя, за исключением мобильных устройств (где нативный код, к сожалению, выигрывает, и это то, что я хочу, чтобы исправить WASM), Интернет по-прежнему в значительной степени плохое отношение к ПК / консоли как с точки зрения производительности, так и с точки зрения монетизации.
5) И наоборот, хотя программирование в спальне / инди-сцена еще не достигла зенита, как несколько лет назад, существует огромное количество веб-разработчиков, которые хотят создавать веб-игры в свободное время. И хотя я не хочу открыто вмешиваться в политику и никоим образом не сбиваю с толку ребят из Unity (я имел дело с некоторыми из них, и это отличный продукт), лично я считаю, что вы должны заботиться об интересах нескольких маленьких парней, а не одного большого парня (это имеет как философский, так и коммерческий смысл).

Я с нетерпением жду вашего выступления @jfbastien :)

@RyanLamansky - Я думаю, вы проводите разумное различие. В отношении:

Насколько мне известно, пункт 1 никем не прорабатывается. Это чрезвычайно сложно, и становится все труднее, поскольку JavaScript продолжает развиваться быстрыми темпами.

На сугубо личном уровне, как человек, который пишет JS по 8 часов в день с 2008 года, я бы очень хотел, чтобы эволюция JS просто остановилась на время и позволила всем остальным наверстать упущенное! Я всегда работал по принципу разработки для наименьшего общего знаменателя, т.е. если он не имеет 100% поддержки, этого не происходит (кроме IE6 / 7/8/9 ;-)). И поэтому мы оказываемся в нелепом положении, когда сосредотачиваемся на модных шаблонах ES6 и предполагаемых сценариях использования, когда у нас даже нет 100% поддержки браузером ES5 для настольных компьютеров и мобильных устройств. Язык явно работает как есть (несмотря на его недостатки), о чем свидетельствует его рыночная доля, так что как насчет того, чтобы мы, как сообщество разработчиков, потратили следующие несколько лет на обучение написанию эффективного, оптимального кода с тем, что у нас есть, а не в очередной раз заново изобретая колесо с новым хипстерским кодом (извините, я попал на территорию разглагольствования ;-))?

Думаю, пора мне надеть пальто ;-)

@RyanLamansky У меня возникло впечатление, что WebAssembly будет просто новой целью для вашего процесса сборки пакетов, и внезапно все станет быстрее. Ясно, что это не так. WebAssembly имеет очень конкретный целевой вариант использования и, вероятно, не будет иметь много возможностей предложить типичному веб-разработчику с большой базой кода JS, полной бизнес-логики.

Но, как вы заметили, в жизненном цикле разработки на основе JS есть некоторые пробелы для более типичных бизнес-ориентированных веб-приложений:
1) Большие пакеты JS имеют значительные накладные расходы на синтаксический анализ и обычно обеспечивают недостаточную обфускацию.
2) В стандартном коде JS отсутствуют аннотации типов (и, возможно, другие подсказки), необходимые для оптимизации кода JIT / Native.

Это предполагает, что возможное решение - это правильно типизированная и аннотированная версия JS, которая дает разработчику более детерминированные и прозрачные пути оптимизации, а также предварительно проанализированную двоичную версию этой версии языка.

В комментариях и документах говорится, что WASM работает помимо JS и использует тот же движок JS браузеров (оптимизированный). https://developer.mozilla.org/en-US/docs/WebAssembly

Я действительно не понимаю этого вопроса.

Извините, что задаю глупый вопрос и делаю глупый комментарий: означают ли вопрос и комментарий команды Webassembly, что Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? Я вижу только субъективные мысли. Кто-нибудь может это объяснить? Если Webasembly быстрее, чем Javascript, почему бы не предоставить транспилятор? Если Javascript невозможен, почему бы не использовать код ES7 / TS? Почему вокруг этого столько секретности?

@ganeshkbhat Первоначальный выпуск WASM представляет собой не более чем компактную двоичную кодировку asm.js, которая является очень строгим подмножеством JavaScript. Он не работает быстрее, чем asm.js, если не используются 64-битные целые числа, поскольку они должны быть эмулированы в asm.js.

Есть предложения добавить в WASM функции, которые приблизят его по возможностям к JavaScript (сборка мусора, интеграция с DOM, потоки), но нет планов по добавлению полного набора функций JavaScript. Так что, скорее всего, транспилятора JS-> WASM никогда не будет. Вместо этого будут созданы новые приложения и библиотеки, предназначенные для работы в рамках ограничений WASM. Сегодня это C и C ++, где языковые ограничения хорошо согласуются с WASM и asm.js.

Нет ни секрета, ни волшебства. Wasm «быстрее, чем JavaScript», потому что это гораздо более простой язык, который намного ближе к оборудованию. JavaScript - сложный язык, который во время выполнения должен делать много дорогостоящих вещей. Он не стал бы волшебным образом быстрее, если бы компилировать его в собственный код через Wasm, а не напрямую.

@ganeshkbhat в настоящее время невозможно размещать объекты внутри asm.js / webassembly. В asm.js и webassembly все операции JavaScript будут использовать один большой массив типов для хранения и загрузки значений. Создание объектов JavaScript (например, var obj = {a: 1, b: 'test'} ) и массивов (например, var a = []; ) невозможно внутри веб-сборки, поскольку еще нет поддержки объектов. Это дизайнерское решение Minimal Viable Product, сделанное для того, чтобы как можно скорее получить поддержку веб-сборки во всех основных браузерах.

В версии будущего, поддержка GC планируется webassembly. Мы (разработчики LeaningTech.com ) работаем над предложением по поддержке объектов в веб-сборке, но это займет некоторое время, чтобы появиться в виде спецификации и реализации во всех основных браузерах. До тех пор невозможно перенести JavaScript (а также CoffeeScript, TypeScript и т. Д.) В веб-сборку. Когда предложение будет принято, появится возможность транспилировать большее подмножество JavaScript , но оно не будет

Конечно. Надеемся на лучшую поддержку JS здесь. Я определенно чувствую, что это можно поддержать. Написание транспилятора - это то, что может понадобиться для языков, поддерживающих типы.

Из того, что я читал о веб-сборке, он ориентирован в основном на веб-браузеры, и в этой области не очень привлекательно иметь компилятор js -> webassembly. Но я могу представить запуск веб-сборки в среде, отличной от браузера. Это не совсем верно, поскольку in также может работать в nodejs, но я вижу его истинный потенциал в средах nodejs в чем-то вроде vertx - polyglot, позволяющем запускать модули, написанные на любом языке, которые могут быть скомпилированы в веб-сборку. Могу представить, что сделать что-то подобное будет крайне сложно. Для этого потребуется множество функций, таких как сборщик мусора, возможно, даже какая-то виртуальная машина, но нет ничего невозможного. Помните, что многие люди тоже скептически относились к asm.js, и взгляните на него сегодня.

Для всех тех, кто (как и я) в восторге от компиляции js -> webassembly, в будущем может быть косвенный и очень ухабистый путь через js -> c -> webassembly с использованием транспилятора проекта

@ mauron85 Среды выполнения без браузера и без JavaScript, безусловно, являются предметом рассмотрения дизайна, просто сегодня существует только JS API.

Со своей стороны, я экспериментировал с системой .NET JIT и не вижу никаких реальных препятствий, кроме времени, и я уверен, что есть и другие, которые хотят интегрировать WASM в свои любимые платформы. Я уверен, что через несколько лет для WebAssembly появятся высококачественные среды выполнения, отличные от JavaScript, единственный открытый вопрос - в какой степени они будут официально одобрены командой WebAssembly.

IMO одно из преимуществ возможности компиляции JavaScript -> WebAssembly заключается в том, что разработчики / сопровождающие библиотек и инструментов Javascript, вероятно, смогут выпустить свои API в двух форматах:

1. в JS (как сейчас), который пользователи могут использовать для браузеров и узлов
2. WASM как скомпилированная библиотека, которая могла бы быть более эффективной.

И это без необходимости когда-либо переписывать существующий код JS на C / C ++, если они хотят раскрыть преимущества производительности WASM в своих библиотеках JS.
Таким образом, разработчики библиотеки по-прежнему смогут разрабатывать и поддерживать на Javascript и производить два вывода для двух разных целей как на JS, так и на WASM.

И использование скомпилированной библиотеки версий WASM определенно будет более эффективным для пользователей, поскольку все, что им нужно сделать, это использовать открытый API из библиотеки, и им, очевидно, будет все равно, написано ли оно на WASM или нет. Но производительность, безусловно, улучшится.

WASM как скомпилированная библиотека, которая может быть более эффективной

Почему? Зачем было бы скопировать веб-сборку с помощью javascript (наихудший сценарий, включая большую часть времени выполнения для механизма javascript в этом двоичном файле; лучший сценарий, включая слой, построенный поверх будущего встроенного wasm GC, который в любом случае несет собственные накладные расходы ) работать быстрее, чем этот javascript, брошенный в jit, посвященный ... запуску javascript?

Хорошо, вы имеете в виду, что это будет еще медленнее с большими накладными расходами?

Возможно, я чего-то не понял. Как C/C++/Rust -> WebAssembly скомпилированный материал действительно эффективен, и даже если в будущем появится поддержка JS -> WASM , которая вызовет накладные расходы? Это потому, что JS - это динамический язык, а C, C ++ и Rust - нет? Или это потому, что JS по своей природе не является полностью скомпилированным языком, в отличие от других языков?

Я полагаю, что компиляция JS в WASM вряд ли повысит стабильную производительность; однако это может улучшить размер кода и время анализа за счет двоичного кодирования, которое по-прежнему полезно.

Я думаю, мы можем просто определить двоичную кодировку для JS и пока игнорировать линейную память и т. Д. Это просто и легко можно заполнить.

@kabirbaidhya Основная проблема с JS -> WASM прямо сейчас заключается в том, что вы не можете создать внутри него эффективный сборщик мусора, поскольку нет возможности проанализировать стек, чтобы увидеть, какие объекты живы. Это означает, что вам придется разместить копию всех ссылок на объекты в линейной памяти (куче) и поддерживать ее синхронизацию, что серьезно снижает производительность. В нем также отсутствует многопоточность с общей памятью, поэтому фоновая сборка мусора невозможна. В будущих версиях WASM можно будет подключиться к механизму сборки мусора хост-браузера, что устранит эту проблему.

Другим серьезным препятствием для JS -> WASM является тот факт, что почти все объекты полностью динамические. WASM по своей сути ожидает, что все будет чисто статическим, поэтому для достижения стандартной производительности JS потребуются сложные слои сопоставления, эмуляция и генерация динамического кода. К счастью, TypeScript помогает в этом, поэтому строгое подмножество TypeScript может быть в какой-то степени нацелено на WASM. Я знаю, что по крайней мере один человек пытается это построить.

C / C ++ хорошо работает с первым выпуском WASM из-за того, что ограничения WASM тесно связаны с ограничениями собственного оборудования, на которые рассчитан C / C ++.

FWIW есть отличная презентация о том, как V8 обрабатывает арифметику JavaScript: https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; dr это всего лишь _one_ пример, в котором реальность намного сложнее, чем может показаться, и на практике не имеет большого значения, поскольку собственная виртуальная машина может (и, вероятно, будет) выполнять работу лучше и быстрее, поскольку она действительно родная и имеет доступ к ресурсов и API wasm никогда не будет - и (вероятно) самое главное - годы итераций.

Это не значит, что _subset_ JS / TypeScript не может успешно распространяться, например ThinScript , TurboScript и т. Д. На первый взгляд они будут очень знакомы JS-программистам.

Я все еще думаю, что это хорошие вопросы, и продолжаю задавать их. Очень важно, чтобы мы все понимали варианты использования и будущее WebAssembly, а также нецели.

6 апреля 2017 года в 00:36 Райан Ламански [email protected] написал:

Другим серьезным препятствием для JS -> WASM является тот факт, что почти все объекты
полностью динамичны. WASM по своей сути ожидает, что все будет чисто
статические, так сложные слои сопоставления, эмуляция и генерация динамического кода
потребуется, чтобы приблизиться к стандартной производительности JS. К счастью,
TypeScript помогает в этом, поэтому строгое подмножество TypeScript может
в некоторой степени нацелены на WASM. Я знаю, что по крайней мере один человек пытается
построить это.

К сожалению, я сомневаюсь, что TypeScript поможет в этом отношении. Охватить
JS наследие, его система типов настолько глубоко и фундаментально несостоятельна, что
интересного «строгого» подмножества нет. Например, такое подмножество
необходимо исключить любое понятие TS о подтипах, что сделало бы его красивым
много бесполезного в своей области.

Были хорошие исследовательские работы, например, о SafeTypeScript, но не
только они более ограничены, они также требуют значительного количества
дорогостоящая дополнительная бухгалтерия и чеки во время выполнения, лишающая цели
обсуждение (и фактически это другой язык, чем JS / TS).

Возможно, я чего-то не понимаю, но одна из идей WebAssembly - напрямую загрузить AST, чтобы избежать времени синтаксического анализа js, верно?

Итак, если у нас есть инструмент, который компилирует js в этот формат ast и передает его браузеру, разве он не выиграет от сокращения времени на синтаксический анализ?

@agnivade , это AST для совершенно другого, гораздо более низкоуровневого языка.

Если бы вы компилировали JS в Wasm в автономном режиме, то да, вам не нужно было бы анализировать на стороне клиента (просто декодировать). В то же время, из-за того, что JS настолько сложен, размер кода резко увеличится, вероятно, в 5 или более раз, что намного дороже. (И это даже без учета того, что вам, вероятно, также потребуется включить в Wasm всю реализацию системы выполнения JS VM, которая легко составляет мегабайты кода.)

Более того, без представления источников вы не можете реализовать большинство динамических оптимизаций, которые имеют решающее значение для быстрого получения JS. Эти оптимизации основаны на перекомпиляции исходного исходного кода и его специализации на основе информации о профилировании. Уже скомпилированный Wasm AST не позволяет этого, вам понадобится AST исходной программы.

@ rossberg-chromium - Большое спасибо. Это многое проясняет! Хотя одно сомнение -

И это даже без учета того, что вам, вероятно, также потребуется включить полную реализацию системы времени выполнения JS VM в Wasm, которая легко представляет собой мегабайты кода.

Зачем вам нужна система времени выполнения виртуальных машин? Разве сам браузер не является средой выполнения виртуальной машины? Я просто хочу, чтобы код был в формате AST, чтобы браузер мог легко начать его выполнять. Я понимаю, что чистый размер увеличится, потому что сам язык сложен, и мы не можем реализовать динамическую оптимизацию. Но зачем нам связывать саму среду выполнения виртуальной машины, если для этого у нас есть браузер?

@agnivade , без динамической оптимизации JavaScript будет медленным, я имею в виду

Под «средой выполнения» я подразумеваю не такие браузерные вещи, как DOM, а простую поддержку языка JS, то есть такие вещи, как сборщик мусора, представления объектов, примитивы и базовые библиотеки и т. Д. Это довольно много для JavaScript, и вы бы нужно заново реализовать все это внутри Wasm.

И, конечно же, вам также понадобится уровень интерфейса для DOM.

Хорошо, я думаю, что теперь понимаю вещи немного лучше. Я думал, что

сборщик мусора, представления объектов, примитивы и базовые библиотеки и т. д.

можно использовать из самого браузера. И я могу просто позволить браузеру загрузить AST и выполнить свою обычную работу. Но теперь я понимаю, что все нужно упаковать внутри самого WASM.

Байт-код универсального языка сценариев был бы интересен! Цель компиляции, разработанная для эффективного переноса и выполнения программ, написанных на динамически типизированных языках со сборкой мусора, со всеми причудливыми крайними случаями популярных из них (javascript, ruby, python, lua), покрытыми (в некоторых случаях) специальными кодами операций и структурами и т. Д.

@distransient , значит, вы хотите комбинаторного безумия всех языков сценариев? Я оптимистично настроен, что человечество сможет собрать инженерные ресурсы, чтобы определить и эффективно реализовать это к 2050 году. :)

Тем, кому интересно компилировать TypeScript в WebAssembly с помощью LLVM. ознакомьтесь с этим расширенным проектом. https://github.com/MichaReiser/speedy.js
Похоже, эта дискуссия никогда не закончится ...

@ rossberg-chromium Я сказал, что это будет "интересно", непросто или красиво 😉

Байт-код универсального языка сценариев был бы интересен ...

Хотя WASM постепенно развивается, чтобы в конечном итоге поддержать такие вещи, как Python, мы могли бы получить первоклассную поддержку для разработки языков сценариев для Интернета гораздо раньше, чем WASM сможет ее предоставить, если бы мы одновременно подходили к проблеме с противоположной стороны.

Для движков JavaScript должно быть относительно просто продемонстрировать свою способность выполнять AST JavaScript, а принятые ими AST могут быть стандартизированы (даже если они сразу же конвертируются в нестандартный промежуточный формат внутренне).

Мы могли бы просто объединить формат AST (например, estree ) и формат сериализации (например, JSON), чтобы создать новый формат файла с новым расширением. Если бы браузеры поддерживали формат в тегах скриптов и т. Д., То такие языки, как TypeScript и CoffeeScript, просто компилировали бы для синтаксического анализа деревьев, и браузер брал бы его оттуда. Транслируемым языкам не нужно было бы генерировать код, и исходные карты также больше не понадобились бы, поскольку лексическая информация была бы основана на фактическом источнике.

Как только базовая поддержка будет установлена, стандарт может постепенно развиваться, чтобы соответствовать WASM в середине, просто добавляя новые типы узлов. Начать можно с простых вещей, например, явных узлов add и concat или, возможно, добавления новых типов данных, таких как DEC64.

По мере того, как WASM расширяется до поддержки языков сценариев, путем добавления таких вещей, как сборщик мусора, выполнение AST будет двигаться вниз, расширяя семантику JavaScript для включения функций из других языков высокого уровня, поэтому более широкий набор языков сценариев может компилироваться в своего рода абстрактный JavaScript .

25 мая 2017 года в 02:57 Карл Смит [email protected] написал:
>

Есть некоторые проблемы, которые необходимо решить, но это было бы
относительно просто для движков JavaScript предоставить свою внутреннюю поддержку
для выполнения AST JavaScript, и принимаемые AST должны быть
стандартизован (даже если AST сразу преобразован в нестандартный,
промежуточные форматы внутри).

Только для более широкого определения термина "относительно простой", чем вы, вероятно,
иметь в виду... ;)

По отношению к WASM все просто.

@bguiz Например:

• Вы не можете изначально перевести JS в ASM, потому что он имеет другую архитектуру.
• Вы не можете управлять DOM из ASM, потому что у вас нет доступа к его ресурсам на уровне процессора.

Движок Google V8 уже компилирует JavaScript непосредственно в машинный код, скомпилировав всю задачу времени выполнения перед ее выполнением.

Таким образом, было бы совершенно ненужно иметь альтернативный конвейер WASM со стороны клиента.

С другой стороны, WASM был представлен с демонстрацией Мандельброта, а затем в первую очередь включает демонстрацию Unity "Tanks", но я очень сомневаюсь, что рисование пикселей с помощью ASM-> CPU (даже с двойной точностью SSE) могло бы быть быстрее. чем WebGL-> GPU, потому что, как заявляет это сообщество, GPU не входит в сферу применения. И что?

@ivanherczeg Ого ! Где это сообщество говорит, что графический процессор не соответствует спецификации?

@SephReed

У нас уже есть разногласия из-за различий между ARM и x86. Я думаю, что добавление еще одного набора аппаратных целей вызовет большую напряженность: большее количество операций либо должно быть медленным из-за затрат на эмуляцию, чтобы получить единообразную семантику для всех целей, либо большее количество операций должно иметь неопределенное поведение, чтобы все могли работать быстро. Думаю, это делает невыгодным рассматривать GPU в настоящее время (или когда-либо).

-Фил

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

Среда выполнения C # была перенесена на wasm и представляла собой полнофункциональный прототип, полностью заменяющий JS. Таким образом, это означает, что в будущем вы можете ожидать появления сред выполнения, которые заменят JS в браузерах и напишут клиентские веб-приложения на Java, C # или даже C ++ с заявлением, в котором говорится: «Код будет работать быстрее, чем нативный» , «Скомпилированный код быстрее, чем виртуальная машина». или что-нибудь еще без помощи JavaScript.

Пожалуйста, посмотрите это видео о том, что я пытаюсь сказать.

WebASM был введен в качестве дополнения к JS, а не полностью, заменив язык первого класса.

В ближайшем будущем вы можете ожидать, что веб-страницы будут доставлены с сервера, скомпилированного изначально.

https://github.com/ballercat/walt

@Steakeye Очень мило :) Я

вы можете скомпилировать JS в WebAssembly с помощью NectarJS. Демо: http://nectar-lang.com/ выберите из раскрывающегося списка WebAssembly

Интересно, что демонстрация NectarJS использует emscripten, вы можете увидеть это в выводе asm.js. Похоже, он статически компилирует JS во что-то - вероятно, C или LLVM IR - а затем запускает это через emscripten.

В выводе wasm также используется emscripten (можно увидеть при просмотре двоичного файла), но он, похоже, использует старую версию, так как испускает двоичные файлы wasm 0xd, которые не работают в современных виртуальных машинах. Он также просто отправляет вам wasm, а не JS, так что он все равно не запускается. В любом случае вполне возможно, что он просто делает то же самое, что и для asm.js, просто запускает emscripten с установленным флагом для вывода wasm.

Демо имеет ограничение на вход в 300 байт, поэтому трудно скормить ему реальную программу, чтобы почувствовать, насколько мощным является их анализ, что является реальным вопросом при таком статическом подходе. В целом академические исследования по этой теме внушают скептицизм.

Их скомпилированные демоверсии для Windows просто рушатся для меня 🤕

Я согласен со скептицизмом @kripken здесь. Я считаю, что произвольный JS невозможно преобразовать в WebAssembly. Любой инструмент, претендующий на достижение этого, вероятно, работает над некоторым подмножеством языка JS или отказывается от производительности выполнения.

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

var a = {prop1: 1};
func(a);

может быть преобразован (в псевдо-изма) в этот

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

Это далеко не тот вызов, который мы можем с полным основанием считать «компиляцией», и он больше похож на развертывание интерпретатора. Конечно, также можно запустить JS-интерпретатор, скомпилированный для Wasm, но это вряд ли приведет к выигрышу в производительности.

JS-движки, такие как V8 и Spidermonkey, могут запускать JS-код так же быстро, как и при его своевременной компиляции. Выполняя JIT-компиляцию, они могут наблюдать, какова реальная предполагаемая семантика для данного фрагмента JS, и генерировать быстрый код для этого конкретного случая, при этом, конечно, проявляя осторожность, чтобы обнаружить любые изменения в среде, которые могут сделать недействительными текущие предположения.

Согласовано. Однако я бы не прочь использовать подмножество JavaScript. Или, может быть, типизированный вариант, который, вероятно, снизит динамизм и позволит генерировать более эффективный код.

Есть какие-нибудь новости по фронту "сильного режима", кстати?

@ Simran-B, мы давно отказались от сильного режима по причинам, изложенным здесь . Вывод состоит в том, что ужесточить семантику JavaScript без потери взаимодействия с существующим кодом практически невозможно.

По той же причине у меня также нет особых надежд на идею разработки «статически компилируемого» диалекта JavaScript или TypeScript - это был бы другой язык, который не может запускать существующий код, так что особого смысла нет.

@ Simran-B: «Я бы не отказался использовать подмножество JavaScript. Или, может быть, типизированный вариант»

В этой области есть очень интересные работы, такие как AssemblyScript, который является строгим подмножеством TypeScript, который компилируется в WebAssembly, https://github.com/AssemblyScript/assemblyscript

@rossberg : «Я также не очень надеюсь на идею разработки« статически компилируемого »диалекта JavaScript или TypeScript - это был бы другой язык, который не может запускать существующий код, так что особого смысла нет».

Я думаю, что большой потенциал таких вещей, как AssemblyScript, заключается не в запуске существующего кода (я согласен с вами в этом, это вообще невозможно), а в том, что наличие дружественного и знакомого языка - это огромное дело.

Прямо сейчас, если вы разработчик TypeScript и хотите написать WebAssembly, вам нужно использовать C ++ или Rust. Оба являются хорошими языками, но у них есть и недостатки. Для кого-то с таким опытом что-то вроде AssemblyScript может быть самым быстрым путем к продуктивности.

Если AssemblyScript может компилироваться как в JavaScript, так и в сборку, это будет идеальным вариантом. С нетерпением жду этих обновлений.

Кроме того, в будущем, если кто-то не сделает это первым, я, вероятно, попробую написать конвертер TypeScript -> Assembly Script, который просматривает файлы, задает вопросы, которые он должен задать, а затем выполняет преобразование. Надеюсь, это сработает!

@SephReed Да, он может компилироваться в JavaScript, потому что есть компилятор WebAssembly -> asm.js , который должен работать со всем кодом WebAssembly.

См. Также «Можно ли использовать WebAssembly с полифиллами?»

Если вместо этого вы имели в виду «возможно ли для AssemblyScript скомпилировать идиоматический код JavaScript?», Тогда я должен спросить, зачем вам это делать, когда WebAssembly / asm.js намного быстрее, чем идиоматический код JavaScript?

Хотя я полагаю, вы сможете запускать код AssemblyScript через компилятор TypeScript. Однако вам нужно помнить о некоторых вещах .

См. Также этот раздел документации AssemblyScript.

Господа, обратите внимание на WALT , язык WebAssembly, подобный JavaScript.

UPD. Извините за некропостинг

Я вижу, что многие люди считают этот компилятор "JS -> WASM" хорошей идеей.

Для тех, кто не считает это полезным, например:

Однако я не уверен, что это будет так полезно с точки зрения разработчика. Вы можете немного уменьшить размер, но не более того. С точки зрения браузера может быть интересно реализовать JS-движок в wasm с точки зрения чистой безопасности.

Пожалуйста, вот мой конкретный пример того, почему это важно и почему это полезно, и не только вы "получите некоторое уменьшение размера, но это все". Одна из функций WebAssembly:

<= XXX « ЗАПИСАННОЕ ОКРУЖЕНИЕ » XXX =>

WebAssembly - это не только производительность. Вы можете увидеть хорошую статью о плагинах от команды Figma .

Создать систему плагинов довольно сложно. Вам нужен хороший способ запустить собственный код. Вам нужна отдельная среда, безопасная.

WebAssembly дает вам это - чистую среду без беспорядка, подобного некоторым глобальным переменным. AssemblyScript делает его в некотором смысле удобным - у вас почти такая же среда TypeScript, что и среда вашего основного приложения, что довольно круто.

Но вот проблема «почти такая же»:

Могу ли я использовать пакеты JS из NPM в моей безопасной среде?

Нет.

Что ж, этот проект WALT - своего рода альтернатива AssemblyScript. Это почти не JS, а типизированный js. Это больше похоже на TS-like. Вы не можете скомпилировать / транспилировать существующие библиотеки js с этим.

Могу ли я использовать пакеты TS от NPM в моей безопасной среде?

Нет.

AssemblyScript - это тоже TS-подобный язык. Он может компилировать что-то написанное на TS, если оно полностью покрыто типами. Без исключений. Никаких any . Но часто у людей недостаточно строгие конфигурации, или у них есть несколько @ts-ignore , или даже чаще - они пишут пакет на js и предоставляют отдельные типы в файлах .d.ts - во всех этих случаях вы не сможет скомпилировать такой пакет в WASM.

@JerryGreen - хорошие

Тем не менее, реальная возможность на самом деле заключается в производительности стартапа , которая приносит пользу практически всем веб-сайтам. Кажется, мало кто говорит о том, что WebAssembly значительно быстрее во время запуска (на байт), что намного превосходит любые преимущества времени выполнения. Вот почему, например, gzip для текстового содержимого, такого как JavaScript, в реальном мире мало влияет на PLT - важен размер скомпилированного кода .

По иронии судьбы, индустрия одержима PLT (временем загрузки страницы) и различными визуальными маркерами завершения, но никто не видит корреляции между WebAssembly и этими векторами? На JavaScript приходится более 30% времени, затрачиваемого до этих критических событий на большинстве веб-сайтов. Фактически, размер страниц и пропускная способность гораздо меньше влияют на PLT по сравнению с линейными факторами производительности, а именно временем запуска JavaScript и задержкой.

С учетом сказанного мне непонятна возможность JS -> WebAssembly.

Подход @JerryGreen Figma является очень специфическим случаем, и я думаю, для большинства проектов iframe или области достаточно хороши для сторонней изоляции javascript. В особых случаях, когда изоляция должна быть более контролируемой, а производительность, размер и время загрузки не так важны, вы всегда можете скомпилировать QuickJS или JavaScriptCore в WebAssembly.

Вы также можете использовать Web Workers и запускать код перед ненадежным кодом, который удаляет все API, к которым у ненадежного кода не должен быть доступ. В этом случае нет необходимости в WASM @JerryGreen!

Падение частоты кадров в трех js в реальной жизни, я не уверен, может ли wasm помочь, но это точно кажется так, по крайней мере, на первый взгляд.

Нет причин компилировать JS в wasm, потому что вам также придется включить целую виртуальную машину javascript. В результате код будет огромным и медленнее, чем изначально предоставленная виртуальная машина JS.

Разве мы не могли бы выполнить всю мономорфизацию и т. Д., Которые выполняются виртуальными машинами JS, с помощью оптимизации на основе

Сборка PGO состоит из двух этапов: первый этап для создания инструментальных двоичных файлов, затем второй этап для повторного построения оптимизированных двоичных файлов с использованием информации профиля, полученной при запуске инструментированных двоичных файлов.

Первый запуск предоставит нам всю информацию о типе (какие функции вызываются с какими типизированными аргументами и т. Д.), Затем мы создаем оптимизированный двоичный файл со всеми вариантами, с которыми вызывается функция (+ общий с динамическими аргументами для непрофилированного кода) . Нам не понадобится вся виртуальная машина JS

PGO требовал отличного тестового покрытия вашей программы. Это не всегда возможно. Но вы можете отслеживать некоторую информацию о типе во время выполнения в v8. См. Этот документ: https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading = h.xgjl2srtytjt

Мы поговорили с командой TypeScript об этой возможности, и они проявили интерес, но похоже, что в настоящее время наблюдается прогресс в добавлении типизированных объектов в JS.

Не нужны типы

Можно ли скомпилировать QuickJS в WASM?

Да, Figma, например, использует QuickJS для своей системы плагинов.

И он также используется в http://numcalc.com/ .