IBM®
Перейти к тексту
    в России и странах СНГ [изменить]    Условия использования
 
 
   
    Главная страница    Продукты    Услуги и решения    Поддержка и загрузка    Мой профиль    
Перейти к тексту

developerWorks Россия  >  Linux  >

Ядерное партнёрство: Часть 2. Использование DDT для зачистки приложений Cell/B.E. от ошибок

Использование Distributed Debugging Tool от компании Allinea для устранения ошибок в приложениях для Cell/B.E.

developerWorks
Опции документа

Опции документа, требующие включения JavaScript, не отображаются

Обсудить


Выскажите мнение об этой странице

Помогите нам улучшить содержание


Уровень сложности: простой

Дэвид Лекомбер, главный директор по технологиям, Allinea Software

17.09.2009

Distributed Debugging Tool (DDT), от компании Allinea Software предоставляет удобный в использовании, эффективный отладочный инструмент, с помощью которого возможна отладка законченных приложений для Cell Broadband Engine, включая анализ многопоточных программ внутри как одного, так и нескольких процессоров Cell/B.E.

Введение

Архитектура Cell Broadband Engine (Cell/B.E.) — это результат сотрудничества компаний IBM, Sony и Toshiba на ниве разработки высокопроизводительного и энергосберегающего процессора, способного выполнять задачи из таких разных областей, как игры, HDTV и высокопроизводительные вычисления. Мультипроцессор Cell/B.E. состоит из:

  • процессорного элемента Power (Power Processing Element, PPE), включающего в себя 64-х битное ядро архитектуры Power или PPU (Power Processing Unit).
  • восьми синергических процессорных элементов (Synergistic Processing Elements, SPE).

PPE — это, по сути, обычный процессор с 256 МБ глобальной памяти, а каждый из процессоров SPE имеет большой набор регистров и локальное хранилище данных объемом 256 КБ. Доступ к общей памяти для процессоров SPE реализован через Direct Memory Access (DMA) с использованием шины данных или путем обмена сообщениями с PPE через систему mailbox.

Программирование процессоров Cell/B.E

Стандартные программы для PowerPC™ могут работать без модификации на таких системах на Cell/B.E., как IBM QS20 BladeCenter® или Sony PS3, с установленными операционными системами Fedora или Yellow Dog Linux®, используя только PPE. Однако пользователи высокопроизводительных систем умеют полностью использовать и ресурсы SPU. Для осуществления этого имеются три основные модели:

  • Прозрачная модель — используются библиотеки, оптимизированные для работы на архитектуре Cell/B.E. Многие высокопроизводительные программы (HPC) используют проприетарные или открытые библиотеки для вычислительного ядра приложения. Эти библиотеки можно перенести на платформу Cell/B.E. Простая перелинковка позволяет приложению воспользоваться новыми библиотеками.
  • Промежуточная модель — используются специальные языки или директивы компилятора. Некоторые из компиляторов и библиотек сторонних фирм умеют оптимизировать передачу данных и процесс распе вычислений между SPU и PPU (PowerPC Processor потребовать переписывания вычислительного ядра приложения или просто добавления директив компилятора, аналогичных распараллеливанию с помощью OpenMP.
  • Прямая модель — использование приложений, написанных с поддержкой как SPU, так и PPU. За передачу и синхронизацию данных отвечают сами приложения. Эта модель обычно используется для прямого управления процессором Cell/B.E., для ручной оптимизации производительности вычислительного ядра или для использования кода, не укладывающегося в модель шаблонов, поддерживаемую современными языками программирования.


В начало


Необходимость отладки

Программирование неотделимо от отладки (или как минимум — от необходимости отладки). Здесь приходит на помощь инструмент DDT от компании Allinea Software (текущая версия 2.1.1). DDT — это отладчик для многопоточных и параллельных приложений. Как и само программирование для процессоров Cell/B.E., отладка таких приложений тоже может сильно отличаться от вашего предыдущего опыта. Использование популярного средства отлова ошибок — отладочной печати — приводит к многочисленным повторам цикла "модификация кода — компиляция — запуск программы", что может сильно отсрочить получение результатов. Также этот метод не очень хорошо работает в многопоточной среде, в том числе в среде Cell/B.E., где выполнение print требует взаимодействия PPU и SPU для вывода сообщения, что может изменить поведение ошибки.

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

Для приложений, написанных специально для платформы Cell/B.E., необходимость в отладке ещё сильнее. В этом случае требование к возможности параллельной отладки SPU и PPU является основополагающим. Необходимо наблюдать за переменными и памятью во всех модулях процессора.

Для промежуточной модели, в которой для приложений Cell/B.E. используются продвинутые возможности компилятора и специальные языки, отладчик, полностью совместимый с Cell/B.E., может дать более полную панораму состояния программы, чем стандартный отладочный инструмент. Например, пользователь можно наблюдать за активными потоками SPE и их развитием на фоне состояний PPU.

DDT разработан специально для отладки программ с высоким коэффициентом распараллеливания, когда иногда одно и тоже приложение может выполняться одновременно на нескольких тысяч процессорах. Но DDT не менее эффективен и на небольших Linux-кластерах. Именно это делает DDT хорошим выбором для отладки приложений для Cell/B.E. Присущая DDT многопоточная модель выполнения и поддержка распараллеливания на уровне интуитивного контроля над процессом, а также развитая система отладки памяти позволяет DDT легко находить типичные ошибки работы с кучей памяти и обнаруживать некорректные чтения.



В начало


Использование DDT

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

Краткое описание приложений Cell/B.E

Приложения для Cell/B.E. состоят из двух частей

  • код для PPU
  • код для SPU

Код для SPU обычно встраивается в двоичный файл PPU на этапе сборки с помощью специальных инструментов из IBM SDK for Multicore Acceleration 3.0 (Cell/B.E. SDK 3.0). Когда DDE загружает приложение для отладки, он автоматически распознаёт инструкции для PPU и SPU и находит файлы с исходным кодом для каждого раздела.

Сначала выполнение программы останавливается на main(), которая является точкой входа. Затем DDT может останавливать процесс при запуске каждого потока SPU, что даёт возможность увидеть, как создаётся поток. Также DDT может останавливать выполнение потока SPU при его завершении, позволяя легко определить причину его завершения. Возможность отслеживания остановок потоков весьма важна. Немедленная остановка потока SPU, причины которой часто трудно понять, может происходить в результате разнообразных ошибок. Например, причиной остановки может стать переполнение стека или недостаток места в локальном хранилище данных.

Моментальный снимок состояния программы

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

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

Parallel Stack View — еще одна популярная функция для обнаружения отклонений в поведении процессоров и потоков. В окне в виде единого дерева отображаются стеки вызовов всех потоков. При желании для программ с несколькими процессорами Cell/B.E. можно показать все потоки всех процессов.

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

Управление PPU и SPU

PPU- и SPU-потоки показываются в верхней части главного окна DDT и обозначаются сокращением PPU или SPU под номером потока. Щелчок мышью на потоке делает его текущим, при этом отображаются переменные, относящиеся к этому потоку.

В коде можно выставить точки останова для PPU и SPU, привязанные к определённым моментам в программе. Точки останова можно назначать как для всех, так и для одного конкретного потока.

С помощью DDT можно управлять всеми или одним конкретным потоком, что позволяет сфокусировать внимание на любом из PPU- или SPU-потоков (пошагово отслеживая каждую строчку исходного кода, в то время как другие потоки поставлены в режим ожидания). Прослеживание выполнения отдельных потоков является одним из наиболее полезных свойств отладчика.

Часто бывает, что программы для Cell/B.E. характеризуются так называемым SIMD-параллелизмом (Single Instruction Multiple Data), при котором все потоки SPU выполняют один и тот же участок кода одновременно. В таких случаях может быть полезно пошаговое выполнение каждого потока по одной строке кода за раз. Разделение потоков может вызвать проблемы. DDT имеет для таких случаев специальный режим, в котором можно выбрать, какие именно потоки примут участие в совместном шаге выполнения, при помощи соответствующей кнопки "step threads together".

Анализ переменных

Каждый SPE и PPE имеет свою собственную адресуемую область памяти. В локальном хранилище SPE содержатся такие данные, как стек и глобальные или статические переменные. Также в нем находится локальная "куча" памяти (heap memory), выделенная данным SPE при помощи системного вызова malloc().

В SPU-программировании существует несколько распространенных ошибок. Глобальные переменные будут глобальными только для одного SPE. Каждый из SPE и PPE будет иметь свои переменные, в отличие от обычного многопоточного программирования, где все процессы используют общую память. DDT может помочь в обнаружении таких проблем с помощью инструмента Cross Thread Comparison, проверяющего переменные с одним идентификатором в каждом SPE- и PPE- потоке. Инструмент идеален для отслеживания неверных значений. Общие переменные группируются вместе, что упрощает анализ изменений в них.

Когда выбран конкретный поток SPU или PPU, значения используемых им переменных отображаются во вкладке Local Variables. Перемещение указателя текущей строки по исходному коду приводит к выделению переменных, используемых в каждой выбранной строке и вычислению их значений во вкладке Current Line. Для пользовательских типов данных (структур, классов и подтипов) содержимое можно получить щелчком мыши на переменной.

Переменные также можно поместить в окно наблюдения (Evaluations box) для более детального анализа. Чтобы отслеживать указатель, нужно щелкнуть по нему правой клавишей мыши и выбрав пункт dereference.

Заключение

Этот краткий обзор отладчика DDT призван показать возможности его применения для улучшения процесса отладки приложений для Cell/B.E. На данный момент DDT доступен для таких платформ Cell/B.E., как IBM QS20 BladeCenter и Sony PS3 под управлением ОС Fedora Core 6 и Cell SDK 2.1. В ближайшее время ожидается выход DDT для SDK 3.0



Ресурсы

Научиться

Получить продукты и технологии

Обсудить


Об авторе

История отношений Дэвида Лекомбера с высокопроизводительными вычислениями началась в 1993 году, когда он работал в группе Oxford BSP над ранней альтернативной моделью параллельного программирования для тогда нового, но сложного стандарта MPI . Он получил степень доктора философии в области параллельных вычислений, написав работу по моделированию систем с общей памятью на базе кластеров с распределённой памятью и формальной семантике для таких кластеров. После получения степени он продолжил работать в Оксфорде в должности преподавателя, а также занимался исследованиями параллельных библиотек и языков программирования. После двух лет разработки сетевых сервисов с высокой нагрузкой для кластеров Java-компьютеров он вернулся в лоно высокопроизводительных вычислений в Allinea Software и занялся разработкой инструментария для параллельного программирования.




Выскажите мнение об этой странице


Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса.



 


 


 


Поделиться этой статьей:

забобрить забобрить memori сохранить в memori




В начало


IBM, BladeCenter и PowerPC являются товарными знаками или зарегистрированными товарными знаками International Business Machines Corporation в США и/или других странах. Linux является зарегистрированным товарным знаком Линуса Торвальдса в США и/или других странах. Другая компания, продукт или название услуги могут быть товарными знаками или знаками обслуживания, принадлежащими иным физическим или юридическим лицам. Другая компания, продукт или название услуги могут быть торговыми марками или знаками обслуживания, принадлежащими иным физическим или юридическим лицам.

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