SWD Software Ltd. - официальный дистрибьютор QNX на территории России и стран бывшего СССР Операционная система реального времени QNX
Инструменты для создания надёжных встраиваемых систем и
интеллектуальных устройств любой сложности
QNX Software Systems - разработчик встраиваемой операционной системы QNX
Информационные брошюры
Статьи и публикации
Обзоры
Операционные системы
Графические интерфейсы
Средства разработки
Прикладные системы на базе ОС QNX
Разное
Конкурсные статьи
Техническая литература
Материалы конференций QNX-Россия
Полезные ссылки
Блог QNX
Главная страница > Материалы > Статьи и публикации > Разное > Перенос существующих приложений на многоядерные процессоры Сделать страницу стартовой Послать ссылку коллеге Версия для печати

Перенос существующих приложений на многоядерные процессоры

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

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

Выпущено множество публикаций о том, что новое поколение многопроцессорных кристаллов приведёт к развитию настольных персональных компьютеров, корпоративных серверов, игровых консолей и домашних мультимедийных центров. Однако если говорить о развитии, то возможности многопроцессорных кристаллов полезнее в оборонной и авиакосмической промышленности. Как и системы в любой другой индустрии, военные компьютеры и подсистемы управления радарами, полётами и объединения датчиков становятся всё более сложными и потребляют значительную вычислительную мощность. Тем не менее, эти системы должны удовлетворять строгим требованиям лёгкости, низкого энергопотребления и теплоотдачи, а также соответствовать спецификациям существующих конструктивов, объединительных плат и корпусов.

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

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

Первое и самое важное решение, которое разработчики должны принять при переходе к многоядерной технологии — это выбор типа параллельной обработки в соответствии с требованиями приложения. Этот выбор определяет, насколько легко будет обеспечить максимальный уровень параллельной работы нового и существующего кода. Как показано в табл. 1, существует три основных типа многопроцессорной обработки: асимметричная многопроцессорность (asymmetric multiprocessing — AMP), симметричная многопроцессорность (symmetric multiprocessing — SMP) и исключительная многопроцессорность (bound multiprocessing — BMP).

Модель Принципы работы Ключевые преимущества
Асимметричная многопроцессорность (AMP) Управление каждым ядром осуществляет отдельная операционная система или отдельная копия операционной системы, общей для нескольких ядер. Обычно каждый программный процесс привязан к одному ядру (например, процесс А выполняется только на ядре 1, процесс Б — только на ядре 2 и т. д.). Асимметричную многопроцессорность также называют архитектурой с независимыми узлами. Обеспечивает среду исполнения, схожую со средой исполнения однопроцессорных систем, что позволяет с легкостью переносить существующий код в AMP-системы. Асимметричная многопроцессорность также даёт разработчикам возможность независимо управлять каждым ядром.
Симметричная многопроцессорность (SMP) Управление всеми процессорными ядрами одновременно осуществляет единственная операционная система. Процессы могут динамически перемещаться между любыми ядрами, что даёт возможность полной загрузки всех ядер. Обеспечивает большую масштабируемость и параллелизм, чем асимметричная многопроцессорность, а также упрощает управление ресурсами.
Исключительная многопроцессорность (BMP) Управление всеми ядрами одновременно осуществляет единственная операционная система. Процессы могут динамически перемещаться между любыми ядрами или быть привязанными к определённому ядру. Обеспечивает масштабируемость и прозрачность управления ресурсами, как симметричная многопроцессорность, и даёт разработчикам возможность управления ядрами, как асимметричная многопроцессорность. Привязка процессов к конкретным ядрам позволяет с лёгкостью переносить существующий код в BMP-системы.

Табл. 1

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

Асимметричная многопроцессорность может быть однородной и неоднородной; в однородных AMP-системах на всех ядрах работают операционные системы одного типа и версии, а в неоднородных AMP-системах операционные системы различаются по типу или версии. В однородной среде разработчики могут максимально эффективно использовать множественные ядра, выбрав операционную систему (например, ОСРВ QNX Neutrino), которая поддерживает модель распределённого программирования. При надлежащей реализации этой модели приложения, которые выполняются на одном ядре, могут прозрачно взаимодействовать с приложениями и службами (к примеру, драйверами устройств, стеками протоколов и т. д.), работающими на других ядрах, без интенсивного использования процессора, которое характерно для традиционных методов межпроцессорного взаимодействия.

Неоднородная среда предъявляет несколько иные требования. Разработчики должны либо реализовать собственную схему взаимодействия процессоров, либо выбрать две операционные системы, которые используют одни и те же протоколы межпроцессорного взаимодействия (как правило, на основе стека IP). Для разрешения конфликтов при использовании ресурсов обе операционные системы также должны обеспечивать стандартизованные механизмы доступа к общим аппаратным компонентам.

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

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

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

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

Дополнительным преимуществом симметричной многопроцессорности является возможность сбора статистики работы всего многоядерного кристалла с помощью инструментов системной трассировки, благодаря которой разработчики получают важную информацию для оптимизации и отладки приложений. Разработчики могут следить за перемещением потоков между ядрами, использованием примитивов операционной системы, планированием событий и передачей сообщений между ядрами, а также получать другую информацию для обеспечения максимальной загрузки каждого ядра. В AMP-системах разработчикам необходимо собирать такую информацию с каждого ядра в отдельности, а затем каким-либо образом объединять её для анализа. На рис. 1 показано использование инструмента системной трассировки, системного профайлера комплекта разработчика QNX Momentics, для анализа четырёхъядерной SMP-системы.


Рис. 1.

На рис. 2 гидроакустический комплекс работает в режиме симметричной многопроцессорности, позволяя выполнять любой поток любого процесса (сбора данных, обработки сигналов, слежения за целью и др.) на любом ядре. К примеру, поток слежения за целью может работать на одном ядре, в то время как поток обработки сигналов выполняет интенсивные вычисления на другом ядре. В такой системе необходимо высокоскоростное взаимодействие между потоками, для реализации которого разработчики могут воспользоваться примитивами локальной операционной системы или синхронизованными защищёнными структурами общедоступной памяти.


Рис. 2.

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

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

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

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

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

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


Рис. 3.

Выбор операционной системы
Операционная система играет ключевую роль в использовании аппаратного параллелизма многоядерных процессоров. К сожалению, существующие операционные системы реального времени, которые применяются в большинстве оборонных и аэрокосмических приложений, не обеспечивают полную поддержку нескольких процессоров, работающих на единой компьютерной платформе, плате или кристалле. Как правило, ядра этих операционных систем способны одновременно управлять только одним процессором или процессорным ядром. Системы с независимыми узлами допускают такое ограничение, но лишаются архитектурной гибкости и не позволяют разработчикам использовать важные преимущества симметричной и исключительной многопроцессорности. Таким образом, важно, чтобы операционная система реального времени, которая выбрана для многоядерной архитектуры, могла одновременно управлять несколькими ядрами и обеспечивала надёжную поддержку всех моделей многопроцессорной обработки, давая разработчикам возможность выбрать оптимальный тип многопроцессорности для решения поставленной задачи. Как показывает табл. 2, гибкость в выборе моделей многопроцессорности позволяет разработчикам достичь наилучшего сочетания производительности, масштабируемости и простоты переноса приложений.

  SMP BMP AMP
Прозрачное совместное использование ресурсов Есть Есть Нет
Возможность использования в системах с тремя и более ядрами Есть Есть Ограничена
Возможность использования нескольких ОС (например, QNX Neutrino и Linux) Нет Нет Есть
Организация процессоров с выделенной функцией Нет Есть Есть
Межъядерный обмен сообщениями Быстрый (примитивы ОС) Быстрый (примитивы ОС) Медленный (приложение)
Межъядерная синхронизация потоков Есть Есть Нет
Динамическое выравнивание загрузки Есть Есть Нет
Отладка и оптимизация в системном масштабе Есть Есть Нет

Табл. 2

Роберт Крейг (Robert Craig) – старший инженер-программист группы разработки ядер операционной системы компании QNX Software Systems. Роберт Крейг обладает более чем 12-летним опытом разработки встраиваемых систем. Он активно работал в качестве архитектора программного обеспечения и руководителя команды разработчиков в различных телекоммуникационных компаниях. Роберту Крейгу присвоена степень бакалавра компьютерных технологий и физики, а также степень доктора философии по физике со специализацией по оптическим компьютерным технологиям.

Поль Леру (Paul Leroux) – технический аналитик компании QNX Software Systems. К сфере его деятельности относятся разработка систем высокой готовности, многопроцессорные системы и архитектура ядер операционных систем.

Рассказать друзьям:

Rambler's Top100           Рейтинг@Mail.ru