Design: pThreads любое ожидаемое время прибытия?

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

У этого проекта нет списка рассылки или другого форума, поэтому трекер проблем — единственное место, где люди могут задавать вопросы о процессе проектирования. Очень важно иметь место, где люди могут задавать вопросы, поэтому я призываю людей продолжать использовать средство отслеживания проблем, чтобы задавать вопросы.

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

Есть публичный список w3 . Однако он не испытывает очень интенсивного трафика. Есть также IRC, я верю? Я думаю, что в какой-то момент это было на веб-сайте, но было бы неплохо, если бы они оба были напрямую связаны в разделе сообщества на веб-сайте. Я бы открыл вопрос, но я не уверен, какие пути вы все предпочли бы, чтобы они были ~выставлены~, связанные с общественностью.

Инструкции здесь:

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

Мы советовали людям использовать github. Не всем это нравится, но лучше иметь одно место, чем много.

Привет @rossberg-chromium и спасибо за своевременный ответ.

Но, пожалуйста, зарезервируйте трекер проблем для регистрации проблем.

Как указал @jfbastien , я спросил здесь, потому что это лучшее место, чтобы сделать это стандартным способом.
Кроме того, поддержка потоков — это конструктивная особенность, от которой зависит решение WebAssembly .
Больше, чем контекст логотипа и «Почему это не реализовано в java», я вижу как проблемы.

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

--Р

@RobertoMalatesta , мы согласны с тем, что потоки очень важны, но сделать их правильными было важнее , чем втиснуть их в минимально жизнеспособный продукт WebAssembly. Наше рассуждение простое: asm.js пользовался успехом и без этой функции.

Потоки определенно являются важной функцией для некоторых важных приложений, но не для всех приложений. То же самое относится к GC, обработке исключений с нулевой стоимостью, гарантированным хвостовым вызовам и т. д.

Выбор сделать MVP означает, что мы не делаем всех счастливыми при первом запуске. Это также означает, что некоторые люди вообще смогут использовать WebAssembly до того, как мы все спроектируем, составим спецификации и внедрим.

При этом мы ожидаем более или менее адаптацию подхода JavaScript SharedArrayBuffer к WebAssembly. Многие из нас были связаны с этой спецификацией с самого начала. Это добавит низкоуровневые возможности, аналогичные тем, что есть в C++, а также API, похожее на фьютексы. У него есть место для роста с большим количеством порядков памяти, чем последовательная согласованность. Продолжается работа по созданию для него формальной модели памяти .

SAB находится на «этапе 4» в TC39, что означает, что он готов, готов к отправке и готов к использованию. Я ожидаю, что внедрение его в WebAssembly не будет слишком сложным.

@jfbastien спасибо за полезную информацию.

При этом мы ожидаем более или менее адаптацию подхода JavaScript SharedArrayBuffer к WebAssembly.(...)
SAB находится на «этапе 4» в TC39, что означает, что он готов, готов к отправке и готов к использованию. Я ожидаю, что внедрение его в WebAssembly не будет слишком сложным.

Здорово. Мне не терпится утомить его большим количеством кода на C++, которому просто не хватает многопоточности.
Я регулярно использую WebWorkers в своих приложениях TS/JS и позвольте мне сказать, что я не фанат их, но они могут быть использованы в качестве первого старта.

потоки очень важны, но сделать их правильными было важнее, чем втиснуть их в минимально жизнеспособный продукт WebAssembly. Наше рассуждение простое: asm.js пользовался успехом и без этой функции.

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

Потоки определенно являются важной функцией для некоторых важных приложений, но не для всех приложений. То же самое относится к GC, обработке исключений с нулевой стоимостью, гарантированным хвостовым вызовам и т. д.

Как давний пользователь emscripten, я хотел бы, чтобы WebAssembly был более отделен от ограничений стека приложений Javascript:

Wasm должен только 1) стремиться к максимальной производительности и 2) предоставлять сокеты, память/потоки, GDI, fs с некоторым стандартом Posix/Unix/BSD. Таким образом, это будет тонкий уровень, похожий на ОС, который можно встраивать как в мобильные устройства в качестве единой целевой платформы, так и в серверы, чтобы конкурировать за развертываемые в облаке приложения.

Это направление, в котором wasm движется в долгосрочной перспективе, или я полностью упустил лодку?

Еще раз спасибо за вашу работу,

Роберто

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

С потоками, особенно если они не основаны на Worker, вы получите больше возможностей.

При этом было бы неплохо получить более подробную информацию о ваших точных идеях. Каков вариант использования, как вы обойдете это в C++ и как это сделают реализации wasm?

Я не ожидаю, что вы найдете ответы на все вопросы! Только то, что сейчас приходит на ум. У Fwiw C++ есть некоторые предложения по ограничениям стека. Проверьте подгруппу SG14.

Извините за мало деталей, я под 👶🌯. Отвечу лучше позже!

Извините за мало подробностей, я под :baby: : burrito:. Отвечу лучше позже!

Ты под детским буррито? Ржу не могу

@qwertie

Ты под детским буррито? Ржу не могу

Буквально, завернутый ребенок.

Привет @jfbastien ,

было бы хорошо получить более подробную информацию о ваших точных идеях. Каков вариант использования, как вы обойдете это в C++ и как это сделают реализации wasm?

Как правило, мой вариант использования заключается в создании программного обеспечения для моделирования, в вычислительной части ограничением является только машина благодаря технологиям C++, C/OpenCL и графическим процессорам.

Во внешнем интерфейсе стек HTML5+CSS+Javascript+Typescript зарекомендовал себя как действительный, проверенный, переносимый способ разработки средних и сложных приложений.

_ Веб-стек JS (с добавлением структурированного языка, такого как Typescript ) настолько хорош в наши дни, что я не чувствую необходимости прибегать к emscripten или пробовать wasm для большинства приложений._

Я почти полностью согласен с High Level Goals и Webassembly Use Cases и даже больше с Non-Web Embeddings Document .

_ W ebAssembly будет актуальной технологией (по крайней мере, для меня), если она позволит быть быстрее (до мозга костей нативного приложения C плюс, скажем, 5% накладных расходов), использовать больше памяти и более свободно, иметь полностью реализованные порты/сокеты и позволять запускать потоки, как это делает любая обычная ОС._

Машина Wasm должна быть очень гладкой по размеру, быстрой и прогнозирующей, поэтому, пожалуйста, не втыкайте в нее GC: GC — это схема Понци в ИТ: вы делаете долги и не заботитесь о распределении до тех пор, пока не станет слишком поздно, и вы потеряете циклы . Кроме того, если у нас есть высокопроизводительная машина с ядром wasm, то на ее основе можно построить GC.

Ради гладкости я бы постепенно отделял его от Javascript. Если у меня есть собственные компиляторы на любом языке, мне не нужны сценарии, и в любом случае я могу встроить Duktape/Lua/что угодно, просто скомпилировав исходники C.

Где-то на сайте Mozilla я видел документы о реализации нативной манипуляции с DOM wasm: я не думаю, что это будет очень полезно, поскольку манипуляция с DOM по своей сути является последовательной и является одним из наиболее трудоемких аспектов стека HTML5/CSS/JS: если Я пишу сверхбыстрый многопоточный wasm только для того, чтобы мои изменения DOM были сериализованы, ожидая в очереди, тогда вся производительность пропала, и лучше транспилировать какой-нибудь Typescript, чем использовать C/C++. В этом случае я бы предпочел прямой доступ к OpenGL (сначала с некоторой реализацией WebGL, а затем с собственным OpenGL). Доступ к графической карте окажется полезным, чтобы предложить возможности GPU/CUDA с небольшими накладными расходами или без них.
(Просто пошел проверить это и получил проблему № 273, решающую эту проблему)

Наличие крошечной машины wasm, совместно используемой всеми поставщиками и независимыми, может решить кошмар мобильной разработки, когда у вас есть как минимум 4 цепочки инструментов для разных ОС, версий и архитектур.
Графические средства и средства ввода могут различаться, но мы сможем разработать один wasm, а затем запросить API-интерфейсы средств или даже развернуть одно и то же приложение в разных магазинах приложений.
В долгосрочной перспективе: то же самое с серверными приложениями, достигнув некоторого консенсуса по средствам (протоколы и пулы подключения к БД, системы желтых страниц, протоколы и системы обмена сообщениями и т. д.) и упаковав их в какую-то стандартную спецификацию, как это сделала платформа JEE. (Большая часть концептуальной работы уже была проделана за последние 20 лет).

Я не ожидаю, что вы найдете ответы на все вопросы! Только то, что сейчас приходит на ум. У Fwiw C++ есть некоторые предложения по ограничениям стека. Проверьте подгруппу SG14.

Конечно, я сделаю.

Спасибо за ваше терпение и время.

Роб

В качестве небольшого дополнения, когда потоки реализованы, было бы здорово, если бы размер стека можно было сделать произвольно большим или вместо этого, если бы он мог быть установлен как минимум на 64 МБ. Это связано с тем, что мой вариант использования — это приложение, использующее 2 потока, а неосновному потоку требуется довольно большой стек.

@jjpe это будет запрос на конкретную цепочку инструментов (например, emscripten), предназначенную для wasm, а не для этого репозитория, потому что это вопрос выбора реализации цепочки инструментов или ABI, а не что-то о платформе wasm как таковой. (например, вы можете открыть вопрос на https://github.com/kripken/emscripten/)

Кое-что из того, что я предложил в своем предыдущем послании, похоже, просто включено в последнее предложение WASI.
Видеть:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Скрещивание пальцев.

--Р

FWIW Текущий статус таков: Chrome предоставляет поддержку потоков wasm в версии 74, Firefox имеет реализацию, которая еще не выпущена, а Emscripten поддерживает pthreads (https://emscripten.org/docs/porting/pthreads.html) с wasm доступен сейчас.

(Кроме того, WASI — это API системных вызовов, который в основном ортогонален тому, поддерживает ли данное встраивание wasm или цепочка инструментов потоки/атомы).

Есть ли какие-либо документы о том, как использовать API потоков Chrome и Firefox?

Это своего рода комбинация вещей. Механизм wasm браузера реализует расширение threads/atomics для спецификации wasm (https://github.com/WebAssembly/threads/tree/master/proposals/threads), которое позволяет создавать экземпляры общей памяти wasm. В Интернете вы можете создать веб-воркер и отправить память (и любые связанные модули wasm) в воркер через postMessage. Затем вы создаете экземпляр модуля с общей памятью на рабочем потоке (и в основном потоке или другом рабочем потоке), и экземпляры совместно используют свою память. В обзоре предложения спецификации (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) есть небольшой пример, но я не знаю других.

Привет @dschuff и спасибо за ответ выше.
В моем предыдущем сообщении я имел в виду предыдущее, включающее не только pthreads, но и желательную эволюцию wasm в нечто более похожее на ядро, что некоторые из нас, следящих за emscripten и использующих его с 2010 года, считали тогда настоящей прорывной технологией.
См.: https://github.com/WebAssembly/design/issues/992#issuecomment-285055578 .

Спустя девять лет после выхода emscripten и почти пять лет после объявления wasm в превращении wasm в жизнеспособную серверную технологию не было достигнуто большого прогресса.

К сожалению, потому что нам нужен стандарт для портативных приложений, и лучшим способом сделать это, ИМХО, было бы реализовать крошечное ядро ​​(подобное BSD/Linux) с потоками POSIX и сокетами Berkeley + автономная безопасная виртуальная файловая система (с пользователями и группы будет достаточно). Я твердо придерживаюсь старой поговорки Х.Спенсера: "Те, кто не понимает UNIX, обречены изобретать ее заново".

Я все еще хочу верить, поэтому WASI — это шаг в правильном направлении.

--Р

PS: 2010 emscripten по-прежнему крут, так как он работает в бессмертном браузере, невыразимо неубиваемом, используемом в большинстве предприятий, и который увидит, как проплывают тела Firefox и Safari (по крайней мере, их движки).