«Открытые системы» , № 02, 2006 515 прочтений
Программное обеспечение многоядерных систем
Нынешний год обещает стать началом массового применения многоядерных систем. Через два года они станут основной платформой серверов, настольных компьютеров и ноутбуков, а в перспективе и встраиваемых систем.
Нынешний год обещает стать началом массового применения многоядерных систем. Через два года они станут основной платформой серверов, настольных компьютеров и ноутбуков, а в перспективе и встраиваемых систем. Однако осуществлению этих прогнозов могут помешать ограничения и нерешенные проблемы программного обеспечения.
Развитие многоядерных систем – это путь к повсеместному использованию параллельных вычислений. Как известно, наиболее распространенным способом повышения производительности является именно распараллеливание потока команд или потока данных. Распараллеливание данных – это применение одной операции сразу к нескольким элементам массива данных. Параллелизм задач предусматривает разбиение вычислительного процесса на несколько подзадач (процессов, потоков), каждая из которых выполняется на своем ядре (процессоре). Многоядерные системы относят к классу MIMD (Multiple Instruction, Multiple Data). В них несколько программных ветвей выполняются одновременно и независимо, но в определенные моменты они обмениваются данными.
Активное внедрение многоядерных систем подразумевает существенное изменение стиля программирования: разработчики будут вынуждены использовать параллельные потоки, порождение и обработку асинхронных событий и др. Иными словами, новая аппаратная архитектура требует смены программной парадигмы – перехода от последовательного стиля программирования к параллельному.
Закон Амдала
Многоядерный процессор – это многопроцессорная система, реализованная на кристалле, обеспечивающая повышение эффективности работы вычислительной системы в целом. Закон Амдала гласит, что прирост производительности (S) системы зависит от количества процессоров (N) и доли последовательных операций (c) в программе:
SБ??1/(с+(1-с)/N)
Граничные значения c соответствуют полностью параллельным (c=0) и полностью последовательным (c=1) программам. Если лишь 1/10 часть программы выполняется последовательно, то в принципе невозможно ускорение в десять раз – вне зависимости от числа используемых процессоров (ядер). Важное следствие закона Амдала состоит в том, что максимальный рост производительности (в N раз при N процессорах) недостижим. В противном случае последовательно исполняемая часть программы должна быть равна нулю, что невозможно. Еще одно следствие закона таково: чем меньше доля последовательно исполняемой части программы, тем больше прирост производительности (рис. 1).
|
| Рис. 1. Следствия закона Амдала |
Сегодня только небольшая часть программного обеспечения может выполняться на многоядерных процессорах, что подтверждают результаты тестов – синтетических и предназначенных для конкретных классов приложений (см., например, www.3dnews.ru/cpu/dualcore-cpu/index03.htm). Реальный рост производительности дают лишь программы, оптимизированные под многопоточность, такие как Adobe Premiere Pro 1.5 и 3DMax. Очень важны разработка и внедрение драйверов устройств, поддерживающих многопоточность.
Особенности перехода к параллельным вычислениям
При переходе с одноядерных процессоров на многоядерные приходится принимать во внимание проблему последовательного выполнения. Что это означает применительно к многоядерной системе? В ней выполнение считается последовательным, если в какой-то момент одно или более ядер не могут выполнять код одновременно с другими ядрами. Такая ситуация может возникнуть по разным причинам [1]: блокировка при доступе к ресурсам, необходимость синхронизации процессов или потоков на ядрах, поддержка когерентности кэш-памяти, неравномерность загрузки.
Блокировки возникают из-за невозможности (например, в момент «сбора мусора») одновременного доступа приложений на разных ядрах к жесткому диску, к устройствам ввода/вывода или данным приложений. Очень часто параллельные процессы, выполняемые на разных ядрах, нужно синхронизировать в определенные моменты. Например, приложение на одном из ядер должно использовать промежуточные данные, которые получает приложение (поток, процесс) на другом ядре. Первое приложение не может продолжить работу до получения этих данных, то есть находится в состоянии ожидания. В такой ситуации неизбежны накладные расходы на синхронизацию приложений (процессов, потоков), выполняемых на разных ядрах. В свою очередь, это обусловливает снижение эффективности параллельной работы, что находит отражение в сетевом законе Амдала. Возникает необходимость в поддержке когерентности (согласованности) кэш-памяти для всех ядер при использовании разделяемой памяти.
Можно упомянуть об исследованиях Intel, посвященных динамическому регулированию интенсивности выполнения инструкций (energy per instruction, EPI) в зависимости от степени параллелизма реализации программного обеспечения [2]. Специалисты корпорации опытным путем показали эффективность регулирования тактовой частоты асимметричной многопроцессорной системы в зависимости от активности вычислительных ядер.
Инструментальные средства многоядерных систем
Компиляторы
Чтобы получить максимальную выгоду от использования многоядерной архитектуры требуется поддержка на уровне компилятора. Так, в 2005 году Intel выпустила версию 9.0 компилятора языков C++ и Фортран для платформ Linux и Windows. Этот компилятор позволяет эффективно использовать возможности технологии Hyper-Threading и многоядерных процессоров. Он поддерживает возможность автопараллелизма, то есть автоматического обнаружения в приложениях возможности создания множества параллельных потоков с поддержкой спецификации OpenMP 2.5.
Благодаря поддержке стандарта OpenMP компилятор Microsoft Visual C++ 2005 обеспечивает параллельную многопоточную обработку. Для этого требуется либо указать параметр компилятора «/openmp», либо установить в конфигурации флаг «OpenMP Support». С ноября 2005 года компилятор gcc для языков Cи, C++ и Фортран 95 поддерживает OpenMP с помощью опции «-fopenmp». Следует упомянуть и набор компиляторов EKOPath компании PathScale, предназначенных для 64-разрядных систем на базе Linux (AMD64 и EM64T).
Литература
- Todd Brian, Putting multicore processing in context: Part one. Embedded.com, February 2006.
- Murali Annavaram, Ed Grochowski, John Shen, Mitigating Amdahl's Law Through EPI Throttling, SCA-32. June 2005, www.princeton.edu/~jdonald/research/cmp/ annavaram_mitigating.pdf.
- Narendar Sahgal, Dion Rodgers, Understanding Intel Virtualization Technology. download.microsoft.com/download/9/8/f/ 98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05015_WinHEC05.ppt.
Сергей Золотарев (zolotarev@rtsoft.msk.ru) и Алексей Рыбаков – сотрудники компании «РТСофт» (Москва).
Согласованное программирование
Совпадение по форме русского слова «конкуренция» и английского concurrency сегодня оказалось крайне неудобным обстоятельством. В момент, когда технологическое направление concurrent programming стало одним из приоритетных, его нечем адекватно назвать. В отличие от «конкуренции», в английском языке основные значения concurrency& – «согласованность», «совпадение во мнении» или даже «соглашение» – не предполагают никакого конфликта, а, совсем наоборот, означают кооперированное взаимодействие. В компьютерной науке под concurrency понимают такое свойство системы, которое позволяет ей распределить общие ресурсы между отдельными вычисленными процессами, накладывающимися друг на друга во времени. Исходя из этого в данном контексте для перевода concurrent programming целесообразно использовать термины «согласование» и «согласованное программирование». Согласованное программирование включает в себя языки и алгоритмы, необходимые для реализации согласованных систем. Более известное параллельное программирование для высокопроизводительных вычислений является частным случаем согласованного программирования.
На академическом уровне проблемами согласованного программирования серьезные исследователи стали заниматься давно и серьезно, еще в конце 60-х годов, наиболее примечательные и фундаментальные работы великого голландца Эдсгера Дейкстры (1930-2002) датируются 1968-м и 1971 годами. Примерно в то же время Карл Петри создал свою теорию сетей, названную его именем.
Но с тех пор ничего более серьезного в области согласованного программирования сделано не было, и это далеко не случайно. Как ни парадоксально, но за прошедшие три-четыре десятилетия практическое программирование достигло больших высот, однако и потеряло немало. В какой-то степени можно даже говорить о частичной деградации: утеряна общая гуманитарная культура, сопутствовавшая программированию в первые десятилетия становления отрасли. Трудно поверить, но в 60-е годы обычных программистов интересовали, например, вопросы структурной лингвистики, они читали работы Ноама Хомского. Если сравнить книги, что тиражами в десятки тысяч экземпляров издавались (необходимо также учесть общее количество компьютеров) и мгновенно раскупались в те годы, с тем, что стоит на полках магазинов сегодня, нетрудно «почувствовать разницу». Причина интеллектуальной стагнации заключается в том, что экспоненциальный рост производительности процессоров сделал ненужными программистские изыски.
Но жизнь устроена так, что за все приходится платить – в том числе за экстенсивное развитие технологии без должного научного, равно как и философско-мировоззренческого обеспечения. Подтверждая это, ведущий эксперт корпорации Microsoft Херб Саттер опубликовал статью «Бесплатный ланч закончился. Фундаментальный поворот по направлению к согласованному программному обеспечению» (Dr. Dobb's Journal, March 2005). На русский язык общий рефрен статьи можно перевести просто: «Конец халяве». Таким образом, даже представитель корпорации, получившей наибольшую выгоду от парадигмы Wintel, существовавшей с 80-х под лозунгом: «Энди (Гроув, Intel) дает, а Билл (Гейтс, Microsift) забирает», признал, что парадигма эта приказала долго жить. Ресурсы трех слонов, на которых стояла вся индустрия, оказались исчерпанными. Тактовая частота не растет; оптимизация исполнения в пределах одного ядра достигла предела, за которым рост сложности становится неоправдан; у дальнейшего наращивания размеров кэш-памяти процессоров остался лишь небольшой зазор для развития. Как следствие, старый добрый мир остался в прошлом; единственным перспективным направлением для дальнейшего развития оказались многоядерные и многопотоковые процессоры.
Метаморфозы в компьютерной отрасли начали происходить на удивление быстро. Ничто не предвещало их еще в начале 2005 года, но уже к его концу многоядерные процессоры стали главными элементами производственных программ ведущих компанийб-разработчиков микропроцессоров.
А что же программирование? Как создавать программы в новом, еще не познанном мире многоядерных процессоров? Сейчас на кристалле их более дюжины, но компания Intel обещает увеличить это число до ста, старая парадигма программирования в этом мире не работает. Тот же Саттер, но уже в статье «Программное обеспечение и революция согласования» (ACM QUEUE, September 2005) называет происходящее революцией по масштабам существенно более мощной, чем распространение обюектно-ориентированного программирования в начале 90-е годов. Тогда причиной перемен стало усложнение программных систем, нынешняя же революционная ситуация вызвана необходимостью выполнять программы на многоядерных и многопотоковых процессорах.
«Послереволюционное» программное обеспечение должно обладать следующими характерными свойствами.
- Для того чтобы использовать ресурсы многопотоковых и многоядерных процессоров, программное обеспечение должно быть по своей природе способным к «согласованию». Понятно, что есть нераспараллеливаемые процессы (их существование обычно характеризуют как «проблему человеческого эмбриона»: девять женщин не могут выносить ребенка за месяц). Однако в современных условиях центров обработки данных задача не состоит в том, чтобы заставить выполнить работу раньше срока, а в том, чтобы в заданный срок сделать как можно больше; в проекции на проблематику воспроизводства населения это означает необходимость максимального увеличения рождаемости.
- Задачи должны стать более адаптированными к использованию ресурсов процессорного ядра, то есть использовать больше времени на полезную работу и меньше на прерывания (это свойство принято обозначать термином CPU-bound, от boundary – «граница», «поверхность соприкосновения»).
- Нужны новые языки программирования, приспособленные к проблемам согласования.
Леонид Черняк
