По словам Дейва Эрмана, разработчики решили прибегнуть к низкоуровневому подходу, чтобы дополнить JavaScript примитивами для распараллеливания кода Источник: Mozilla |
В корпорации Mozilla работают над средствами распараллеливания кода JavaScript, которые позволили бы при его выполнении в полном объеме задействовать доступные аппаратные ресурсы.
Дейв Эрман, ведущий научный сотрудник и директор по стратегии исследовательского подразделения Mozilla, сообщил в блоге об экспериментах, которые ведутся с JavaScript-движком SpiderMonkey: разработчики решили прибегнуть к низкоуровневому подходу, чтобы дополнить JavaScript примитивами для распараллеливания кода. «Сегодня развитие JavaScript резко ускорилось: на подходе EcmaScript 6, между JIT-компиляторами идет бескомпромиссная борьба за лидерство по скорости, — пишет Эрман. — Но есть область, где JavaScript пока еще отстает; это параллелизм — возможность одновременного выполнения нескольких потоков команд на аппаратных ускорителях».
Параллелизм, подчеркнул Эрман, нужен, чтобы «раскрыть мощь, таящуюся в доступных нам инструментах: графических процессорах, SIMD-инструкциях и множественных процессорных ядрах». «Благодаря развивающимся стандартам WebGL 2.0 и SIMD в соответствующих областях происходит колоссальный прогресс, — добавил он. — А технология Web Workers позволяет контенту выполнять скрипты в фоновых потоках, но только в изоляции от пользовательского интерфейса».
Распараллеливание в Mozilla предполагают обеспечить через интерфейс программирования SharedBufferArray, поддерживаемый SpiderMonkey. Разработчики готовят черновик спецификации на базе этого API, прототип которой уже поддерживается в еженощных сборках Firefox. По словам Эрмана, в Mozilla ждут пользовательских откликов о новой технологии.
Переменная типа SharedArrayBuffer дает веб-воркерам новые типы блокировок, при этом появляется вероятность того, что между некоторыми объектами могут возникать гонки данных. «Но в отличие от проекта Nashorn в Java, это может произойти только с объектами, которые пользуются общей памятью в качестве резервного хранилища, — если вы создаете объект без использования общего буфера, можно быть уверенным, что гонок не будет. Воркеры автоматически не делают память общей — для них надо заранее согласовывать совместное использование буфера для массивов», — поясняет он.
Эрман подчеркнул, что разработки Mozilla в области параллелизма не имеют отношения к конкурентности — механизмам, позволяющим программе реагировать на одновременно происходящие события. «Асинхронная модель конкурентности в JavaScript широко и с успехом используется, а с предстоящим появлением ‘обещаний’ (promises), генераторов (generators) и структуры async/await она станет еще лучше», — убежден он.
Один из возможных вариантов реализовать параллелизм — воспользоваться в JavaScript моделью многопоточной работы с данными, предложенной в рамках проекта Nashorn. Но этот подход несовершенен: «Если ваша хостовая Java-программа не будет синхронизировать скрипты, вы лишитесь гарантий выполнения приложений JavaScript до завершения. Честно говоря, на сегодня я не вижу возможности рассматривать этот вариант».
Между тем специалисты Mozilla и Intel Labs завершили работу над API для детерминированного распараллеливания. «Целью этих экспериментов было найти высокоуровневые абстракции, которые позволили бы добиться ускорения выполнения кода за счет распараллеливания и при этом были лишены недостатков, свойственных многопоточной обработке, — пояснил Эрман. — Это непростая задача, поскольку трудно придумать универсальные модели, которые подходили бы для широкого круга параллельных программ».