Является ли веб-рабочий более тяжелым или более легким, чем собственный поток

Question

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

Я рассматриваю experimental support of pthread в emscripten, несколько потоков в C++ будут переведены на веб-работников после компиляции. Но будет ли он иметь тот же уровень производительности, что и собственный код? Ведь мелкозернистая многопоточность является ключевой особенностью C++.

Answer 1

В настоящий момент WebWorkers довольно тяжеловес, потому что виртуальная машина дублирует кучу своего внутреннего состояния (иногда даже код повторного JIT для рабочего). Это состояние много больше, чем несколько бит MiB из собственного потока и связанное состояние.

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

Это означает, что в конце вашего вопроса намекает на недоразумение того, какие потоки накладных расходов и как работает предложение для SharedArrayBuffer (которое Emscripten использует для поддержки pthreads). На данный момент WebWorkers тяжелы, но они могут взаимодействовать через SAB точно так же, как собственный код, такой как C++, может: путем доступа к точно такой же памяти на том же виртуальном адресе. SAB добавляет новый тип ArrayBuffer к JavaScript, который не получается кастрированным, когда вы его используете postMessage другому работнику. Затем несколько рабочих могут видеть обновления другого работника в буфере точно так же, как и код C++, когда вы используете std::atomic.

В то же время рабочие не могут блокировать основной поток по определению и, следовательно, имеют более «родное» чувство. Некоторые веб-API недоступны для всех работников, но это меняется. Это становится актуальным, если вы, например, написать игру и иметь сетевые/аудио/рендеринг/AI/ввод в разных потоках. Интернет медленно находит свой собственный способ сделать это.

Подробности немного сложнее

SAB в настоящее время поддерживает только неатомарные доступы, и последовательно-последовательное доступы (т.е. единственным доступным Atomic доступа на данный момент является такой же, как C++ с std::memory_order_seq_cst). Выполнение неатомных обращений должно быть примерно таким же сильным, как и неатомтика C++ (большие оговорки компилятора здесь, в которые я не буду входить), а использование Atomic должно быть примерно таким же, как и дляC++ по умолчанию (std::memory_order_seq_cst). C++ имеет 5 других заказов на память (relaxed, consume, acquire, release, acq_rel), которые SAB в настоящий момент не поддерживает. Эти другие заказы памяти позволяют в некоторых случаях ускорять работу с собственным кодом, но их труднее использовать правильно и переносимо. Они могут быть добавлены к будущим обновлениям SAB, например. через this issue.

SAB также поддерживает Futex, которые нативные программы полагаются на под капотом, чтобы реализовать эффективные mutex.

Есть даже более сложные данные по сравнению с C++, I've detailed some of them, но есть еще больше.