Design: почему не java или .net?

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

Я предполагаю, что это потому, что .net и jvm - это не только байт-код, это виртуальная машина со своей собственной сборкой мусора, загрузчиком классов и отражением. WebAssembly на самом деле представляет собой платформу низкоуровневых операций, не зависящую от браузера. Я думаю, вы могли бы запустить JVM в WebAssembly, но это не дало бы желаемого результата. Он просто добавит время запуска WebAssembly и время запуска JVM. И у вас будет две разные кучи собранного мусора. Один из JavaScript, а другой из вашей новой JVM. Я думаю, что сейчас тебе лучше с GWT.

Правильнее рассматривать Web Assembly как эволюцию asm.js, а не как совершенно новую технологию. Единственная возможность, которую он действительно имеет над asm.js, - это 64-битные целые числа, которые даже не нужны для большинства программ. Этот ограниченный объем позволяет относительно легко интегрировать его в существующие движки JavaScript.

Один из ветеранов проекта Web Assembly, вероятно, получит более полный ответ, и я согласен, что это был бы хороший пункт часто задаваемых вопросов, поскольку он, вероятно, будет часто появляться после выхода 1.0.

Байт-коды Jvm и .Net специализируются на соответствующих виртуальных машинах, каждая из которых имеет свои собственные проблемы и проблемные области, которые они пытаются решить отдельно от виртуальных машин, запущенных в веб-браузерах. Адаптация всей второй виртуальной машины для работы в веб-браузерах была бы обременительной для пользователей, а адаптация API Jvm и .Net vm для работы на существующих виртуальных машинах была бы обременительной с точки зрения реализации и неизбежно обременительной для пользователей и, возможно, более подверженной ошибкам / ошибкам, поскольку сложность растет. Веб-сборка разработана как более простой ISA, который можно легко запускать на существующих виртуальных машинах Javascript уже в браузерах, с акцентом на оптимизацию времени транспортировки и загрузки, набор требований, существующих байт-кодов, не удовлетворяет должным образом.

Я был уверен, что у нас есть что-то об этом в документах FAQ или Rationale. Мы этого не делаем. Было бы отличным дополнением.

@ kovalenko0 Если я могу высказать свое мнение. JVM и .net не очень хорошо зарекомендовали себя в Интернете, потому что они добавили бы значительную поверхность атаки и, следовательно, значительную нагрузку, а также раздувание. Если в будущем они смогут работать в песочнице wasm, это добавит уровень защиты, который может снизить нагрузку. На данный момент Wasm, похоже, сосредоточен на низкоуровневом языке, близком к оборудованию, и, надеюсь, с гораздо меньшей поверхностью атаки для его песочницы и, надеюсь, хорошей целью для кода в целом. Были и другие очень важные попытки на языках низкого уровня, таких как NaCL, но, на мой взгляд, они потерпели неудачу, потому что было слишком низкоуровневое развертывание готового нативного кода, который требовал проверки. Мы надеемся, что Wasm - это просто немного более высокий уровень со слоем трансляции, который дает немного больше гибкости и позволяет перенацеливать на любой процессор, а также открывает путь для более общей проверки и запекания этих выводов проверки в оптимизированный код.

@ kovalenko0 О, и заставить всех поставщиков веб-браузеров согласиться

Я готов написать дополнение к FAQ, объединив здесь ответы, но каков процесс участия в этом проекте?

Убедитесь, что вы присоединились к группе сообщества, а затем отправьте PR в
дизайнерское репо.

Пт, 27 января 2017 г., в 19:56, Райан Ламански [email protected]
написал:

Я готов написать дополнение к FAQ, объединив ответы
здесь, но каков процесс участия в этом проекте?

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/WebAssembly/design/issues/960#issuecomment-275744408 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALnq1BziU5qIZOBNq5fBYLfOjoeOkMIzks5rWj3SgaJpZM4LmzIH
.

Вносящие подробности. На них есть ссылки со страницы "нового PR" 😁

Изначально я планировал добавить раздел под LLVM, но, поскольку этот раздел был написан в 2015 году, некоторые его части устарели. Например...

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

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

Сейчас я подумываю о замене раздела LLVM более общим обсуждением существующих байтовых кодов (упоминая LLVM, Java и .NET в качестве примеров), сформулированным с гораздо большей уверенностью в подходе, принятом командой WebAssembly.

Есть возражения?

@Kardax, что делать с разделом LLVM, будет до @dschuff / @sunfishcode.

@kardax Возможно, лучше ничего не добавлять, потому что у разных дизайнов есть много плюсов и минусов, и все же есть много улучшений, которые можно было бы внести в wasm. Asm.js мог с вашей точки зрения «работать безупречно» и в некоторых отношениях иметь лучшую производительность, чем wasm, так что это еще не все. Возможно, вы захотите изучить время синтаксического анализа / декодирования и компиляции и производительность.

@wllang ... о чем ты говоришь? Я никогда не говорил, что ASM.JS работает лучше, чем WASM. Думаю, вы совершенно неверно истолковали то, что я написал. Я также категорически не согласен с тем, что в текущую двоичную кодировку WASM для MVP нужно внести много улучшений; Я бы сказал, что это примерно на 98% хорошо, и я могу жить без последних 2%.

@dschuff / @sunfishcode Продолжает ли продолжительное обсуждение битового кода LLVM? Я думаю, что жизнеспособность специализированного двоичного кодирования была полностью доказана, поэтому мы могли бы убить трех зайцев одним выстрелом, обратившись к промежуточным форматам LLVM, Java и .NET в одном разделе.

@Kardax Извините, я не имел в виду, что вы «сказали, что ASM.JS имеет лучшую производительность, чем WASM». Но, например, Asm.js имеет постоянные переменные модуля, и они могут быть встроены в скомпилированный код, а это то, чего нет в wasm, и это было очень полезно, и для получения аналогичной функции в wasm требуется код пользователя для перезаписи модуля.

Как группа может объективно оценить утверждение о том, что wasm находится в пределах 2% от `` готово к работе '' (что бы это ни значило) Знаем ли мы, какова наилучшая возможная производительность, лучший размер кодирования, лучшая скорость декодирования и компиляции и т. Д., Самая низкая использование ресурсов декодирования-компиляции и т. д.? Мы не хотим делать это личным, не то чтобы кто-то знал лучше, и даже ответить на такое требование очень сложно, нам нужно поговорить о технических идеях, которые можно оценить по техническим характеристикам.

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

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

@Kardax Да, обсуждение LLVM IR по-прежнему актуально, по крайней мере, для некоторых аудиторий.

Кроме того, вы упоминаете «жизнеспособность» и «безупречную работу», но я бы предположил, что на этом уровне это по сути считается само собой разумеющимся. Можно было заставить работать множество вещей; вопрос в том, почему был выбран один вместо других?

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

Я все же думаю, что это актуально для FAQ.

Открыт №1061.

FWIW кто-то в Microsoft получил интерпретатор .NET, работающий на WebAssembly в качестве эксперимента: https://github.com/SteveSanderson/Blazor

https://github.com/appcypher/awesome-wasm-langs