Design: Что такое потоки веб-сборки?

Похоже, есть версия emscripten-fastcomp, которая использует WebWorkers для реализации потоков:
https://github.com/juj/emscripten-fastcomp/tree/pthreads

Поскольку потоки в настоящее время перечислены как функция post-v1 , нужно ли нам разбираться в этом до публичного объявления?

Согласен, переход к этапу нет.

В связи с этой проблемой в # 103 я предлагаю взглянуть на гарантии продвижения вперед, как это определено комитетом по стандартам C ++.

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

Во время первоначальной дискуссии с @ncbray о

При использовании _worker-based thread_ для создания потока приложение wasm создавало воркера (в версии 1, вызывая JS; после интеграции WebIDL, импортировав Worker API и создавая воркера напрямую). Чтобы разделить кучу wasm / глобальное состояние между рабочими, сам объект модуля wasm должен быть postMessage() ed непосредственно для целевого рабочего, симметрично тому, как один разделяет SharedArrayBuffer ( импорт модуля WebAssembly будет повторно импортирован в пункт назначения).

Плюсы:

• симметрично очевидному отображению pthreads-to-asm.js + SAB, которое у Юкки работает и проходит набор тестов pthread.
• любое количество модулей wasm может совместно использоваться любым количеством рабочих процессов, что позволяет создавать очень выразительные конфигурации в сценариях использования wasm, не связанных с полным портом приложения.
• Никаких реальных изменений для веб-платформы или веб-API по сравнению с JS + SAB.

Минусы:

• В настоящее время у воркеров довольно много памяти (из-за того, что каждый из них включает независимый контекст выполнения JS ( JSRuntime / Isolate и т. Д.)).
• Хотя для воркера определенно _возможно_ избежать создания контекста JS, если JS не импортирован в воркер (после интеграции wasm + WebIDL), это не будет простой задачей impl (из-за случайных зависимостей и сквозного характер рабочих). Кроме того, существует случай динамического импорта JS (в работнике, ранее не использовавшем JS) и накладных расходов, не связанных с JS, искоренить которые может быть труднее. Определенно интересно услышать, что другие браузеры говорят по этому поводу. Но я беспокоюсь, что потоки не будут сокращаться во всех браузерах в течение многих лет.

Итак, альтернативой являются потоки, определенные чисто WebAssembly. По сути, спецификация будет определять, как вы создаете, уничтожаете, объединяете и т. Д. Потоки. Логически потоки будут «внутри» модуля, и все потоки будут иметь доступ к одним и тем же глобальным объектам, импортам и т. Д. Что происходит, когда неосновной поток вызывает импорт, который (в браузере) является JS? (Вся эта идея от @ncbray) Вызывающий поток будет заблокирован, и вызов будет выполнен в основном потоке модуля (тот, в который был загружен модуль, который имеет четко определенный Realm т. Д.) , как если бы по setTimeout(importedFun.bind(args to import call)) .

Плюсы:

• По своей конструкции каждый поток, созданный WebAssembly, мог быть не чем иным, как потоком ОС. Никакой специальной работы не требуется, что означает, что потоки затрат на ОС с первого дня во всех браузерах, реализующих эту функцию, не требуются.
• В конечном итоге нам может потребоваться выполнение некоторых операций над потоками, которые не нужны рабочим процессам (скажем, pthread_kill ...).

Минусы:

• Увеличенная задержка по сравнению с узким местом синхронного вызова и сериализации в основном потоке. Обходной путь здесь заключается в том, что, когда мы получаем привязки WebIDL, мы могли бы определить механизм согласия (например, новый атрибут метода WebIDL), который объявляет API, что они могут вызываться синхронно из потоков wasm.

Если не рассматривать их как взаимоисключающие, можно предположить захватывающий гибрид:

• Модуль может использоваться многими воркерами (как описано выше) и внутри каждого воркера может форкнуть любое количество потоков pure-wasm, содержащихся в этом модуле worker +.
  
  
  
  • Содержащий воркер будет «основным потоком» для вызовов импорта в потоках pure-wasm.
  
  
• Это позволяет приложению wasm точно контролировать, сколько циклов событий и контекстов JS оно создает.
  
  
  
  • Например, я бы ожидать, что игра один OffscreenCanvas работника (без чистого wasm нитей, просто делает на рабочем потоке без перерыва), один IDB работник (возможно, несколько чисто wasm потоков), и один «все другие фоновые потоки "worker" (со всеми другими потоками как потоки pure-wasm).
  
  
  • В пределе, после того как все важные веб-API были помечены как вызываемые непосредственно из потоков pure-wasm, идеальное приложение создавало бы исключительно потоки pure-wasm.
  
  

С точки зрения точки зрения веб-платформы, я думаю, что ни один из них не меняет принципиально модель, если мы тщательно определяем такие вещи, как состояние стека объектов настроек скрипта (опять же, аналогично setTimeout ). Кроме того, потоки pure-wasm описываются и полифилируются в терминах asm.js + SAB: вызывающий неосновной поток использует разделяемую память для постановки работы в очередь для основного потока, а затем futexWait() s для ответа.

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

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

Мы также можем развивать веб-платформу двумя способами:

• Разрешить использование некоторых веб-API, таких как GL, вне основного потока, но только из одного потока.
• Однако этот подход не работает для многих сценариев использования файловой системы: приложения ожидают, что смогут read / write из нескольких потоков без выполнения неявных переходов, и на самом деле нет веских причин для запрета этого. Мы можем указать некоторые API для работы с несколькими потоками wasm (с некоторыми ограничениями).

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

С тех пор, как мы поговорили, я пытался распутать неясный, волосатый клубок взаимодействующих проблем и неартикулированных начальных точек (re: api surface + ffi + thread) и разбить их на более мелкие куски, о которых мы могли бы поговорить. Надеюсь, я скоро начну публиковать некоторые проблемы, до тех пор считайте это размахивающим рукой заглушкой из-за плохой поддержки.

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

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

Я не верю, что мы хотим, чтобы рабочие становились «потоками из ниоткуда», вызывая любой код WASM, который им нравится. Какой идентификатор pthreads они получают? Как работает TLS? Если управление потоками не является герметичным для WASM, придется ответить на несколько сложных вопросов.

Однако мне нравится код WASM, взаимодействующий с произвольными исполнителями. Что-то вроде портов сообщений + массовые копии данных, если ничего другого? (Да, это похоже на шаг назад, я постараюсь обосновать это в другом месте.)

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

Примечание: по крайней мере, в Chrome я знаю, что многие рабочие API реализуются путем подпрыгивания через основной поток. Значит, явное узкое место в основном потоке может не сильно повлиять на производительность в краткосрочной перспективе?

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

Примечание: неявный мьютекс хранилища кажется ожидаемым тупиком, хотя я не могу найти никаких API-интерфейсов, которые действительно получают его у рабочего ...

Во вторник, 9 июня 2015 г., в 2:05 Ник Брей [email protected] написал:

С тех пор, как мы поговорили, я пытался разгадать непонятный, волосатый клубок
взаимодействующие проблемы и нечетко сформулированные отправные точки (re: api surface + ffi

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

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

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

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

Я не верю, что мы хотим, чтобы рабочие превратились в «потоки из ниоткуда»
вызов любого кода WASM, который им нравится. Какой идентификатор pthreads они получают?
Как работает TLS? Если управление потоками не является герметичным для WASM, существуют
придется ответить на несколько сложных вопросов.

Вопрос в том, как воркер попадет в wasm-код? Им придется
каким-то образом получить ссылку на модуль wasm, предположительно с помощью этого первого
postMessage () обратился к ним.

Однако мне нравится код WASM, взаимодействующий с произвольными исполнителями. Что-то
по линии портов сообщений + массовые копии данных, если не что иное? (Да,
это похоже на шаг назад, я постараюсь обосновать это в другом месте.)

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

Примечание: по крайней мере, в Chrome я знаю, что многие рабочие API реализованы
подпрыгивая через основной поток. Так явно узкое место через
основной поток может не сильно повредить производительности в краткосрочной перспективе?

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

Примечание: неявный мьютекс хранилища кажется ожидающим тупика,
хотя я не могу найти никаких API, которые действительно приобретают его у рабочего ...

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

Согласитесь с @titzer, что мы, возможно, захотим поддержать программирование в асинхронном стиле, позволив wasm напрямую участвовать в цикле событий (что даже не является натяжкой). На высоком уровне, я думаю, мы увидим:

1. Приложения с переносимым C ++ POV, которые не нуждаются в асинхронности, им нужны чистые потоки и многие из них, и они могут ограничиться потоками pure-wasm (с использованием рабочих только для того, чтобы избежать узких мест, пока все важные веб-API не будут вызываться непосредственно из чистого wasm темы).
2. Приложения с веб-POV, которые состоят из модулей JS, модулей wasm, основаны на популярных веб-фреймворках, используют массу асинхронности. Именно здесь нам определенно нужна полная мощь shared-wasm-in-worker и хорошая интеграция с циклом событий, обещаниями и т. Д.

и я думаю, что оба варианта использования будут иметь большое значение в обозримом будущем.

С точки зрения C ++, мы могли бы сопоставить 2 точки зрения, которые предлагает

1. База кода, экспортирующая _start .
2. Кодовая база, которая экспортирует что-то вроде обработчика select или epoll .

Интерпретатор (lua, python, ...) может хорошо вписаться в 2, а реализации могут объединять обработку цикла событий JS с обработкой событий модуля wasm, включая обработку некоторых файловых дескрипторов и конвейеров, которые JS обычно не может делать, но wasm модуль мог. Чтобы было ясно, я не говорю, что мы выставляем epoll как есть, но что-то близкое к этому, что по-прежнему хорошо вписывается в веб-платформу.

IIUC, select / epoll будет означать синхронную блокировку ограниченного набора событий цикла событий. Это давно предлагается независимо для рабочих в JS, и мы, вероятно, должны продвигать это вперед (это сквозное расширение платформы, которое, вероятно, имеет широкие семантические последствия, а не то, что мы можем просто сделать локально в wasm), но я думаю если мы хотим интегрироваться с _existing_ веб-платформой, это не логические примитивы для этого: мы должны разрешить возврат в цикл событий, что означает регистрацию wasm в качестве обработчика onmessage рабочего (что может быть выражены в стиле wasm-y) и участвуют в других формах очередей микро / нано / пикозадач, уже определенных в спецификации HTML5. То есть, если вы можете заставить браузер вызывать JS, у вас должна быть возможность заставить его вызывать wasm (что бессмысленно возможно в MVP, поскольку вы можете просто заставить JS вызывать wasm, но мы теоретизируем мир, в котором рабочий (или даже основной поток) _only_ содержит wasm). (Исключение: я могу навсегда оставить встроенные обработчики событий как JS-файлы :)

Если можно, выскажу несколько мыслей о серверных вещах (в частности, об узле). Существует три основных варианта использования потоков (для них, вероятно, есть «правильные» имена, но вы поймете идею):

• Вычислительно-тяжелая нативная работа. У них нет стека JS. Значения передаются, устанавливается обратный вызов, и когда числа обработаны, обратный вызов получает возвращаемое значение.
• Немедленный выход из потока. Передается один файл с необязательными аргументами, который выполняется до завершения, в течение которого возвращаемые значения могут быть отправлены обратно в родительский поток. У этого есть два варианта.
  
  
  
  • Нет потока доступа к вводу-выводу. Созданный поток по существу является синхронным, но для дальнейшего ограничения объема работы, которую могут выполнять эти потоки, им также не разрешается выполнять какие-либо операции ввода-вывода синхронизации.
  
  
  • Поток ввода-вывода. Разрешено запрашивать другие модули и выполнять синхронизацию ввода-вывода.
  
  
• Поток цикла событий. По сути, это похоже на запущенный процесс. За исключением того, как они общаются и имеют возможность делиться памятью.

У них есть вариации того, как разработчики хотят их реализовать. Подобно тому, как немедленно выходящий поток создает каждый раз новый стек JS или использует новый. Закрывается ли поток после завершения или повторного использования операции. А также поток, синхронизируемый или асинхронный, присоединяющийся к основному потоку до тех пор, пока порожденный поток не будет завершен.

Извините, если это было слишком много примеров. Я понимаю, что способность wasm работать с потоками будет либо недостаточно низким, либо достаточно обширным, чтобы удовлетворить эти потребности (я не ожидаю, что это могло бы быть в отношении первого примера). Оставляя серверным приложениям необходимость использовать свои собственные привязки. Это правильно?

У меня нет ответов на все, но я могу прокомментировать то, что потоки WebAssembly будут иметь доступ к API уровня pthreads, поэтому приложения будут иметь довольно большой контроль. Такие решения, как когда и как использовать pthread_join, в значительной степени определяются приложением (или библиотекой, связанной с приложением).

Кроме того, сам WebAssembly разработан так, чтобы быть независимым от JS, и можно будет иметь потоки WebAssembly без JS-кода в стеке.

Спасибо. Приятно слышать.

Что здесь нам нужно решить для MVP, и что может подождать, пока мы действительно не введем разделяемую память?

Я не вижу, чтобы это что-то напрямую блокировало в MVP. При этом для чего-то столь центрального кажется, что у нас должно быть довольно четкое представление об этой функции (и некоторый экспериментальный опыт) до того, как MVP будет окончательно доработан / выпущен. Однако я не вижу "block_binary".

Несколько проблем с WebWorkers подробно описаны здесь: https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/2

FWIW, и то, и другое - подразумеваемые проблемы, которые мы ожидаем решить в FF.

@lukewagner , это не совсем вопросы реализации. Семантика запуска воркера разрешена спецификацией воркера. Ограничение количества потоков является следствием желания предотвратить атаки DOS, но оно очень грубое и что-то лучшее, с наблюдаемостью (т. Е. Исключение, возникающее при неудаче создания рабочего), будет приветствоваться многими приложениями, но, вероятно, требует спецификации тоже меняются. Вдобавок, насколько я могу судить, нет способа определить, ушел ли работник, что является странной дырой в спецификации, но я не нашел для этого механизма.

@ lars-t-hansen Что касается рабочих, которые не запускаются до возврата в цикл событий, когда вы говорите «разрешено спецификацией», вы имеете в виду, что спецификация не указывает, когда будет достигнут прогресс, или конкретно упоминается этот случай? Что касается ограничения количества потоков, вы правы, что необходимо (в дополнение к более высокой квоте) - это некоторая видимая ошибка, указывающая, что квота превышена.

Я думаю, что гарантия продвижения вперед - это то, что мы здесь хотим, в соответствии с докладом Торвальда Ригеля N4439 комитету по стандартам C ++ .

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

@jfbastien , я еще не читал эту статью, но согласен, что-то подобное желательно.

(Я напишу нашим специалистам по веб-стандартам относительно спецификации Worker.)

Еще пара заметок о рабочих. Центральная часть - это спецификация WHATWG 10.2.4, Модель обработки.

• Алгоритм «запустить рабочий»: «1. Создайте отдельную среду параллельного выполнения (т. Е. Отдельный поток, процесс или эквивалентную конструкцию) и выполните остальные шаги в этом контексте»). Это в значительной степени подразумевает («параллельный», «поток или процесс»), что исполнителю требуется настоящий параллелизм, запрещающий как задержку возврата к циклу события, так и неопределенную задержку ожидания ресурса.
• Алгоритм «убить рабочего» имеет интересное примечание: «Пользовательские агенты могут вызывать модель обработки« убить рабочего »для рабочего в любое время», т. Е. Рабочий может просто умереть без всякой причины. (И не очевидно, что это непосредственно наблюдается.)

@ lars-t-hansen Ха, хороший момент относительно наблюдаемости через сеть (особенно если принять во внимание синхронизацию XHR в основном потоке)> :)

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

@lukewagner , Спецификация сервис-

Сообщение об ошибке противоречит спецификации WHATWG здесь: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29039.

@slightlyoff, вероятно, может

Я предполагаю, что запуск webasm в строго однопроцессных средах будет возможен, даже если спецификация потребует наличия API уровня pthreads? Поскольку параллелизм, в отличие от параллелизма, не может быть гарантирован, реализация могла бы просто обрабатывать созданные «pthreads» как блоки для произвольного планирования?

Будут ли в спецификации гарантированы какие-либо гарантии более строгие, чем в режиме мягкого реального времени?

@emanuelpalm согласился, допустимая реализация может имитировать однопроцессорную систему.

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

Я очень рад этому:
http://images.nvidia.com/events/sc15/SC5105-open-source-cuda-compiler.html
https://developer.nvidia.com/CUDA-LLVM-Compiler

Есть ли какие-либо мысли о возможности реализации параллельного цикла forall в веб-сборке?

Как мог бы выглядеть конвейер как конкретный способ эксперимента?
web assembly -> wasm binary -> chrome -> gpu

Кажется, удобнее иметь что-то вроде:
web assembly -> binary (jit?) -> chrome -> gpu

@jbondc Я думаю, что ваше мышление ближе к TS параллелизма C ++, который требует поддержки во время выполнения. Это было бы возможно, но в настоящее время у WebAssembly нет постоянной работы для графических процессоров. Это важно, но не в первую очередь для MVP. Работа команды Роберта сильно отличается от того, что сделала бы WebAssembly (хотя она могла бы выиграть от этой работы).

Да, это выглядит правильно:
https://github.com/cplusplus/parallelism-ts/blob/master/parallelism-ts.pdf

Но больше заинтересован в написании моего собственного языка, который компилируется до Web Assembly (и имеет поддержку параллелизма).

Я думаю, что лучшее, что wasm может и должен сделать, - это предоставить необработанные аппаратные примитивы для параллелизма ( потоки и SIMD ) в рамках универсальной модели ЦП, принятой WebAssembly, авторам языка / библиотеки / инструмента, оставив существующие и будущие веб-API на усмотрение доступ к оборудованию за пределами ЦП общего назначения (например, WebGL для графического процессора). Затем авторы языка / библиотеки / инструмента могут создавать абстракции, нацеленные на конкретную модель параллелизма. (По сути, это просто аргумент Extensible Web .) Исходя из этого, я бы подумал, что библиотеки в TS параллелизма C ++ будут предоставляться в виде библиотек поверх вышеупомянутых примитивов веб-платформы, а не как встроенные функции (по крайней мере, не в ближайшей перспективе).

Мысли примерно так:
http://www.actor-framework.org/pdf/manual.pdf
https://github.com/actor-framework/actor-framework
https://www.youtube.com/watch?v=VOFOj3LLXRk

Это возможная история?

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

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

Это не абстракция более высокого уровня. «Модель актера» (https://en.wikipedia.org/wiki/Actor_model) - это другая теоретическая модель для размышлений о вычислениях (по сравнению с конечной машиной Тьюринга).

На основе аппаратного обеспечения (например, графического процессора от Nvidia) вы можете реализовать в виртуальной машине некоторую вещь, передающую обмен сообщениями. На мой взгляд, если в Chrome, Chakra, Firefox или Webkit будет реализовано сопоставление с образцом + вещь с актером, то мы получим параллелизм C ++ бесплатно, совместное использование памяти + потоки и почти любую другую параллельную модель.

Связано на случай, если кто-то захочет взломать что-то вместе:
https://github.com/solodon4/Mach7

@jbondc Это не SMP, и вы сомневаетесь, что сможет реализовать SMP-код с любым уровнем эффективности? Подумайте, как он мог бы реализовать атомарно обновляемые стеки, очереди, кеши и т. Д. В коде, написанном для общей памяти? Запланированная поддержка wasm должна позволить реализовать некоторые из этих языков программирования «Модель акторов» в wasm, а атомарные операции могут использоваться для реализации быстрых очередей сообщений и управления памятью для разделения акторов и т. Д.

@JSStats Я больше пытаюсь найти хорошие строительные блоки. Лучшее оборудование уже здесь.

Здесь есть хорошее обсуждение оборудования:
http://amturing.acm.org/acm_tcc_webcasts.cfm (Компьютерная архитектура)

Плохой дизайн потоков / общей памяти.
Actor Model Хьюитта или его разновидность - лучший способ.

В качестве конкретного примера это хорошая работа:
http://2014.rtss.org/wp-content/uploads/2014/12/RTSS2014-sifakis-distr.pdf

Страница 34. Плохие потоки.
Стр. 48. Хорошая модель.

Стр. 59-60. Здесь может применяться ~ 'двоичный jit': Распределенный генератор BIP.

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

Перенос этой вехи в Post-MVP, чтобы веха MVP фокусировалась на практических задачах для MVP. Очевидно, что планирование потоков важно, но, как мне кажется, осведомленность уже достаточно высока, поэтому нам не нужно напоминать об этой проблеме. Если люди не согласны, я могу вернуть его.

@jbondc Если вы планируете провести несколько экспериментов, откройте новый выпуск, чтобы сообщить о своих результатах. Спасибо!

@sunfishcode Подойдет , но в основном отказался.

Для всех, кто интересуется BIP:
http://www-verimag.imag.fr/New-BIP-tools.html

Неужели мы думаем о потоках WASM, что такой код компилируется в атомарные операции загрузки / сохранения?

class FastBlockableMutex {
 protected:
  atomic<bool> mIsLocked;
  atomic<int> mWaiters;
  atomic<int> mBlockers;
  mutex mMutex;

};

@jbondc потребуются инструкции для
Да, атомарный доступ будет до тех пор, пока размер не заблокирован. Скорее всего, мьютекс перейдет в атомарный, а затем в какой-нибудь фьютекс. Ожидаю, что модель будет близка к этой .

@jbondc - это не идея предоставлять потоки, сравнивать и менять местами и т. д., чтобы можно было построить на его основе реализацию актора без блокировки?

@malthe Я, после некоторых исследований, пониланг делает:
https://github.com/ponylang/ponyc/blob/master/src/libponyrt/actor/actor.c
https://github.com/ponylang/ponyc/blob/master/src/common/pony/detail/atomics.h

Также есть несколько интересных паттернов параллелизма с HPX:
https://www.youtube.com/watch?v=6Z3_qaFYF84&feature=youtu.be&t=16m1s
https://github.com/STEllAR-GROUP/hpx/tree/master/external/atomic/boost/atomic/detail

А потом программирование на GPU:
https://www.youtube.com/watch?v=KHa-OSrZPGo
https://github.com/ponylang/ponyc/issues/1330
http://llvm.org/docs/NVPTXUsage.html

@binji обратится к предложению в