Max Home IndustryСтарые программисты параллельного программирования скажут вам, что одно из первых правил параллелизма — больше не обязательно лучше. Теперь у нас есть некоторые исследования, подтверждающие это некоторыми данными. Хорошая новость заключается в том, что в ближайшем будущем мы можем продолжать жить как есть, но в долгосрочной перспективе нам может понадобиться что-то другое.
Поскольку на смену гонке за все более быстрыми процессорами пришла гонка за втискивание большего количества ядер в один чип, параллельное программирование стало частью повседневного программирования. Мы считаем само собой разумеющимся, что чем больше ядер и больше потоков, тем выше производительность. Старые программисты параллельного программирования скажут вам, что одно из первых правил параллелизма — больше не обязательно лучше. Теперь у нас есть некоторые исследования, подтверждающие это некоторыми данными. Хорошая новость заключается в том, что в ближайшем будущем мы сможем продолжить работу, но в долгосрочной перспективе, когда мы сможем работать с более чем 48 ядрами, нам может понадобиться что-то другое.
Группа исследователей Массачусетского технологического института в документе, представляемом на симпозиуме USENIX по проектированию и внедрению операционных систем в Торонто, утверждают, что, по крайней мере, в течение следующих нескольких лет операционная система Linux должна быть в состоянии идти в ногу с изменениями в конструкции микросхем — но в в долгосрочной перспективе нам действительно нужно действовать по-другому.
Они взяли реальную систему с восемью шестиядерными чипами и использовали ее для тестирования производительности алгоритмов, использующих до 48 ядер. Они обнаружили, что после добавления нескольких ядер дополнительные ядра замедляли работу системы, а не ускоряли ее. Причина в большинстве случаев связана с разделением памяти. Чтобы система могла удалять общие данные, ядро поддерживает центральный счетчик ссылок на использование.
По мере увеличения количества ядер и, следовательно, потоков синхронизированное управление счетчиком использования занимало все больше и больше времени. Простое изменение в ведении локального счета, который иногда синхронизируется с центральным счетчиком, ускорило процесс. Так называемые неаккуратные счетчики не приводят к точному центральному счету в любой момент времени, но рано или поздно счет становится надежным, и его можно использовать, чтобы указать, когда следует удалить указанную память.
Обратите внимание, что это изменение не в использовании потоковой передачи в приложении, а в ядре Linux — 3002 строки изменений, если быть точным. Причина столь обширных изменений заключалась в том, что счетчики ссылок были реализованы во многих различных подсистемах — объектах записей каталога, объектах файловой системы, объектах сетевой маршрутизации и т. Д.
Также стоит отметить, что были доступны проприетарные системы с 1000 процессорами и более, но с модифицированными операционными системами. Это исследование посвящено стандартным стандартным Linux и архитектуре x86.
Авторы статьи приходят к выводу, что это небольшое изменение и частичное доказательство того, что все переделки, которые происходили в процессе масштабирования ядра Linux, более или менее сработали и что общий подход к нему хороший. Другими словами, единственное, что нужно было изменить, — это возиться, а не полностью переписывать. С изменениями все приложения хорошо масштабируются до 48 ядер. Что происходит после 48 — хороший вопрос. Как отмечают авторы статьи, по мере увеличения количества ядер становятся важными различные узкие места.