Является ли веб-работник тяжелее или легче, чем собственный поток
Является ли веб-работник просто обычным собственным потоком, созданным браузером для запуска и связи с другими потоками браузера с помощью очереди сообщений? Или не содержит других вещей при создании?
Я смотрю на экспериментальная поддержка pthread в emscripten несколько потоков в C ++ будут преобразованы веб-работникам после компиляции. Но будет ли он иметь такой же уровень производительности, как и нативный код? В конце концов, мелкозернистая многопоточность является ключевой особенностью C ++.
Решение
На данный момент WebWorkers довольно тяжеловесны, потому что виртуальная машина дублирует часть своего внутреннего состояния (иногда даже повторно JIT-код для работника). Это состояние много больше, чем несколько MiB собственных потоков исходного пространства стека и связанного состояния.
Часть этого может быть исправлена реализациями, и я ожидаю, что если SharedArrayBuffer или же WebAssembly + потоки стать популярным, тогда браузерные движки захотят оптимизировать вещи.
При этом конец вашего вопроса намекает на недопонимание того, что такое издержки потоков и как работает предложение для 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::atomic по умолчанию (который std::memory_order_seq_cst). C ++ имеет 5 других порядков памяти (relaxed, consume, acquire, release, acq_rel) который САБ не поддерживает в данный момент. Эти другие порядки памяти позволяют нативный код быть быстрее в некоторых обстоятельствах, но труднее использовать правильно и переносимо. Они могут быть добавлены в будущие обновления SAB, например, через Эта проблема.
SAB также поддерживает Futex какие нативные программы используют для реализации эффективного mutex,
Есть еще более хитрые детали по сравнению с C ++, Я подробно описал некоторые из них но есть еще больше.
Другие решения
Других решений пока нет …