CC BY
14
6. Т h ai n D., Tannenbaum Т., L i v n у M. Condor and the grid / / Grid computing: making the global infractructure a reality / Ed. by F. Berman, A.J.G. Hey, G. Fox. John Wiley, 2003. P. 299-336.
7. I рек E., Su pin ski B.R. de, Schultz M., McKee S.A. An approach to performance prediction for parallel applications // Euro-Par 2005 Parallel Processing. V. 3648/2005. Lisbon, 2005. P. 196-205.
8. Балашов В.В., Капитонова А.П., Костенко В.А.,Смелянский Р.Л., Ющенко Н.В. Методика оценки времени выполнения программ, оптимизированных под конкретную архитектуру процессора, по тексту программ на языке высокого уровня // Сб. докл. 1-й Междунар. конф. "Цифровая обработка сигналов и ее применения". Т. IV. М.: МЦНТИ, 2005. С. 203-220.
9. Булочникова Н.М., Горицкая В.Ю., Сальников А.Н. Система сбора и анализа статистики о работе вычислительной системы // Тр. науч. конф. "Методы и средства обработки информации". М.: Изд. отдел ф-та ВМиК МГУ, 2005. С. 136-141.
10. http://www.regatta.cs.msu.su/
11. http://www-cgi.cs.purdue.edu/cgi-bin/acc/pses.cgi
12. Воронов В. Ю., Г о р и ц к ая В.Ю.,Зленко П.А., Истомин Т.Е., Королев Л.Н., Мещеряков Д. К., Попова H.H., Сальников А.Н. Система обработки экспериментальных данных // Тр. науч. конф. "Методы и средства обработки информации". М.: Изд. отдел ф-та ВМиК МГУ, 2005. С. 213-219.
Поступила в редакцию 27.11.06
УДК 519.687.1
И. В. Машечкин, А. А. Смирнов
ПОИСК МЕСТ СОЗДАНИЯ КОНСИСТЕНТНЫХ КОНТРОЛЬНЫХ ТОЧЕК В ПАРАЛЛЕЛЬНЫХ ПРОГРАММАХ ПУТЕМ АНАЛИЗА ТРАССЫ ПРОГРАММЫ
(кафедра автоматизации систем вычислительных комплексов факультета ВМиК, e-mail: [email protected])
1. Введение. Контрольная точка (КТ) — информация о состоянии задачи, которая позволяет продолжить ее выполнение с данного момента времени. Механизм контрольных точек для параллельных программ применяется для обеспечения отказоустойчивости, а также для того, чтобы предоставить возможности более гибкого планирования задач в параллельной вычислительной системе [1].
Создание контрольных точек для параллельных программ, использующих библиотеку MPI, имеет свою специфику: кроме состояния каждой ветви как последовательной программы в контрольную точку входит состояние коммуникационной среды, также невозможно одновременно сохранить состояние всех ветвей параллельной программы. В силу этого для обеспечения корректного восстановления из контрольной точки вводятся ограничения на состояние задачи в момент создания контрольной точки. Контрольная точка называется консистентной, если при восстановлении из нее не будет потеряно или продублировано ни одно сообщение.
Рассмотрим механизм создания контрольных точек для параллельной MPI-программы [2] (библиотека libcheckpoint). Эта библиотека обеспечивает создание консистентных контрольных точек, если в момент создания контрольной точки выполнены следующие условия (в дальнейшем будем называть их критериями консистентности).
1. Ни один процесс не заблокирован в состоянии ожидания сообщения.
1 Работа выполнена при поддержке Российского фонда фундаментальных исследований, проект № 05-01-00719-а.
2. Ни одно сообщение не находится в буферах MPI и в коммуникационных каналах. (Все сообщения отправлены; все операции по приему сообщений завершены, т.е. содержимое сообщения скопировано в буфер программы.)
Кроме того, библиотека libcheckpoint требует явного указания мест создания контрольных точек в исходном коде программы (при этом выбранные места должны удовлетворять критерию консистент-ности). Выбор таких мест может быть осуществлен вручную программистом, так как в некоторых задачах это сделать достаточно просто: критериям консистентности обычно удовлетворяет окончание внешней итерации, состояние после выполнения групповой операции MPI, затрагивающей все процессы, и т.п. В данной статье будет рассмотрен подход, позволяющий автоматически выявлять места в параллельной программе, в которых возможно создание консистентных контрольных точек, в тех ситуациях, когда выявление таких мест вручную затруднительно. Этот подход основан на анализе трассы параллельной программы.
2. Детерминированность MPI-программ. Так как наш подход основывается на такой статической характеристике задачи, как ее трасса, мы должны сделать предположения о том, что трасса исследуемой задачи не изменяется от запуска к запуску или изменяется контролируемым образом. Источником недетерминированности для последовательной программы является ее взаимодействие с окружением. Поскольку каждая ветвь параллельной программы представляет собой последовательную программу, ее недетерминированность (т.е. различие трассы программы от запуска к запуску) может быть обусловлена:
1) обращением к недетерминированным вызовам MPI;
2) зависимостью от входных данных;
3) другими причинами (например, использование датчика псевдослучайных чисел, взаимодействие с другими процессами, минуя средства MPI, и т.п.).
Мы не будем рассматривать программы, в которых недетерминированность обусловлена третьим пунктом. Разрабатываемый нами подход может быть применен к некоторым задачам, трасса которых изменяется в зависимости от входных данных, а недетерминированность, связанная с вызовом MPI-функций, может быть проанализирована.
Отметим, что в стандарте MPI отдельно отмечены источники потенциальной недетерминированности: ими являются неблокирующие операции и получение сообщения без указания отправителя или тега (MPI_ANY_TAG и MPI_ANY_SOURCE). Необходимо заметить, что такие потенциально недетерминированные вызовы могут оказаться детерминированными, например вызов функции получения сообщения без указания отправителя при условии, что только одно сообщение может быть получено в данный момент. Для сообщений, отправленных от одного процесса к другому с одним тегом, порядок сохраняется (FIFO).
Под отсутствием зависимости трассы MPI-программы от входных данных понимается не отсутствие изменений в результатах работы программы и не отсутствие изменений в содержимом передаваемых через MPI сообщений, а неизменность последовательности событий отправки и приема сообщений.
3. Причинно-следственные зависимости. Введем некоторые термины.
Момент отправки сообщения — момент вызова одной из функций семейства MPI_{,B,S,R,l}send. Нам не важен фактический момент отправки сообщения, так как он произойдет заведомо раньше, чем завершится соответствующий ему прием сообщения, а в промежутке времени между отправкой сообщения и его приемом контрольная точка создаваться не может.
Момент приема сообщения — момент возврата из функции MPI_Recv или соответствующей для MPI_Irecv функции, сообщающей об успешном приеме сообщения.
Действие параллельной программы — это операция по приему или отправке сообщения (мы не рассматриваем внутренние действия, такие, как вычисления, так как они не влияют на выбор места создания контрольной точки).
Определим понятие причинно-следственного предшествования между двумя действиями.
1. Два действия одного процесса причинно-следственно предшествуют, если одно следует за другим (во времени).
2. Действие по отправке сообщения одного процесса причинно-следственно предшествует соответствующему ему действию по приему этого сообщения в другом процессе.
3. Два любых других действия причинно-следственно предшествуют, если существует цепочка действий, начинающаяся с первого действия и заканчивающаяся последним, такая, что два любых соседних действия в этой цепочке причинно-следственно предшествуют друг другу в смысле пунктов 1 и 2.
Обозначим отношение причинно-следственного предшествования между действиями символом 'Ч".
Причинно-следственное предшествование на множестве действий является отношением частичного порядка. Действительно, оно антирефлексивно (очевидно), транзитивно (следует из пункта 3 определения).
Отношение причинно-следственного предшествования очень удобно при анализе параллельных программ, оно позволяет сформулировать простое необходимое условие консистентности, обнаружить соответствующие друг другу операции по приему и отправке сообщений, а также проводить анализ потенциально недетерминированных мест в параллельных программах. Однако выявление данного отношения является сложной задачей, поэтому при анализе используется еще одно понятие — векторный таймер.
Показания компьютерных часов на узлах паралелльного компьютера невозможно синхронизировать с точностью, необходимой для упорядочения событий в параллельной программе. Так как нет необходимости точно измерять промежутки времени между событиями, а достаточно лишь определить их порядок, применяют подходы, не использующие системных часов. Например, одним из таких подходов являются часы Лампорта [3].
Рассмотрим более сложный механизм, находящийся в непосредственной связи с причинно-следственным предшествованием. Каждая ветвь г параллельной программы поддерживает внутренние часы Тг, являющиеся целочисленным вектором длины га, где га — количество ветвей программы. В начале выполнения программы в каждой ветви часы инициализируются значением [0, 0,..., 0]. Перед выполнением действия по отправке сообщения ветвь с номером I увеличивает компоненту Т\ своего таймера на единицу: Т\ = Т\ + 1. К каждому отправляемому сообщению ветвь прикрепляет текущее показание часов. При получении сообщения ветвь ] получает также показания часов отправителя Тг и устанавливает свои часы в значение = тах(Г^,Г^) \/к 6 {1 ...га}, а затем увеличивает "свою" компоненту часов: Т3- = Т3- + 1. На множестве показаний часов (на множестве целочисленных векторов длины га) можно определить отношение частичного порядка "<":
rpi грЗ 1к 1к
^ 1. Описание такого рода векторных часов и
Т1 < Т3 У к £ {1.. .га} : Т{ <С Т3, £
к= 1
примеры их использования для анализа параллельных программ можно найти, например, в работах [4, 5].
Будем называть показаниями часов, соответствующими действию параллельной программы, показания часов ветви, выполнившей действие после выполнения данного действия. Тогда имеют место следующие два утверждения.
Утверждение 1. Пусть имеет место цепочка действий, причинно-следственно предшествующих друг другу, а -< Ь ... -< с, тогда соответствующие им показания часов связаны соотношением Та <ТЬ < ...<ТС.
Утверждение 2. Пусть есть цепочка показаний часов, соответствующих действиям в параллельной программе, связанных соотношением Та < Тъ < ... < Тс, тогда соответствующие им действия причинно-следственно предшествуют: а Ь -< ... -< с.
Из этих двух утверждений вытекает, что а -< Ь ^ Та < Тъ. Следовательно, данное определение таймера удовлетворяет условиям часов Лампорта, описанным в [3].
4. Алгоритм поиска мест создания консистентных контрольных точек. Для поиска возможных мест создания консистентных контрольных точек достаточно зафиксировать действия параллельной программы. Поэтому трассой параллельной программы мы будем называть просто последовательность действий параллельной программы. Для каждого действия в трассе должен быть записан тип действия, номер ветви, в которой оно произошло, таймер, связанный с данным действием. Также записывается дополнительная информация о действии, позволяющая улучшить анализ: момент времени, когда действие произошло (относительно ветви, выполнившей действие), место в исходном коде программы, откуда произошло обращение к данной функции MPI, и т.п.
Для определения места создания контрольной точки в параллельной программе необходимо указать момент создания контрольной точки в каждой ветви программы. Контрольные точки могут быть поставлены между любыми двумя действиями в параллельной программе. На практике создание контрольной точки может осуществляться непосредственно до или после действия (напомним, что под действием понимается прием, отправка сообщения и т.п.). Такая комбинация из п выбранных мест создания контрольной точки (по одному в каждой ветви) может быть оценена с точки зрения удовлетворения требований, сформулированных в разделе 1, а также с точки зрения других критериев, таких, как:
• удобство для программиста исходной задачи: контрольные точки во всех ветвях создаются на одной и той же строчке исходного кода программы, при каждом входе на строчку может быть создана контрольная точка;
• эффективность: ожидаемое время синхронизации (время, которое потребуется для того, чтобы все ветви программы достигли места создания контрольной точки) является малым;
• интервал между контрольными точками: временной интервал между выбранными контрольными точками удовлетворяет требованиям, которые пользователь предъявил перед анализом.
Сформулируем необходимые требования к месту контрольной точки (из раздела 1), выразив их в терминах трассы параллельной программы. Пусть контрольная точка в ветви I создается после действия a¿ и перед действием При вызове функции создания контрольной точки будет выполнена синхронизация, т.е. программа будет приостановлена до тех пор, пока все ветви не сделают вызова функции создания контрольной точки. Такой вызов они могут сделать только тогда, когда все действия a¿ завершатся; отметим, что в этот момент действия 6¿ еще заведомо не выполнятся. Запишем необходимое условие создания контрольной точки:
Ук,1 Е {1,.. .,п} : <ц / Ьк.
Эта запись означает, что действие, предшествующее созданию контрольной точки, не может причинно-следственно следовать за действием в любой ветви программы, которое будет выполнено после создания контрольной точки. Пусть, например, а\ У 63. Тогда контрольная точка не может быть создана до того, как произойдет действие а\, но оно не может иметь место до того, как будет выполнено действие 63, которое произойдет только после создания контрольной точки. Данная ситуация является тупиковой.
Достаточным условием возможности создания контрольной точки в выбранных местах является завершенность всех операций по передаче и приему сообщений. Так, если все операции завершены, то ни один процесс не может быть заблокирован в состоянии получения сообщений и все отправленные сообщения должны быть получены (коммуникационные каналы и буферы МР1 пусты).
Рассмотрим алгоритм поиска возможных мест создания контрольных точек. В тексте алгоритма будут использованы следующие обозначения:
п — количество ветвей (процессов) в параллельной задаче;
е^ — действие, непосредственно следующее за действием е^ в ветви ].
Алгоритм 1. Поиск возможных мест создания консистентных контрольных точек с использованием трассы МП-программы.
1. Рассмотрим все возможные наборы действий длины п, в которых все действия произошли в разных ветвях: {е\,е2, ■ ■ • ,е„}. При этом пусть действие е^ произошло в ветви г.
2. Если для \И 6 {1,..., п} в паре (е^, ¿¿) оба действия являются детерминированными, а для набора действий {в1, ег,...,еп} выполненено достаточное условие консистентности2 контрольной точки, то контрольную точку можно создать в данном месте выполнения параллельной программы (в ветви I контрольную точку можно создать между действиями е^ и ¿¿).
Рассмотрим некоторые способы ускорения работы данного переборного алгоритма.
Утверждение 3. Если для набора действий Е\ = {(е^ , ё^), (е,2, ¿¿2),..., (е^ , ё{к)} не выполнено необходимое условие консистентности, тогда для УЕ2 : Е\ С Е2 необходимое условие также не выполнено, т. е. набор Е\ не может входить ни в одно возможное место создания контрольной точки.
Доказательство очевидно, поэтому здесь не приводится.
Для анализа завершенности действий введем дополнительные функции от действий:
2В момент времени непосредственно после завершения действий е\, е-2, ■ ■ ■ , еп все операции по приему-передаче сообщений завершены.
starts(e) возвращает пару {rank s start, rank s-complete), где rank s start — множество номеров процессов, которые начали действие (всегда один элемент — номер текущего процесса); rank s-complete — множесто номеров процессов, в которых должно произойти действие, связанное с данным, которое завершит данную операцию;
completes (е) возвращает пару (rank s start, rank s-complete), где ranksstart — множество номеров процессов, которые должны выполнить действие, связанное с данным, чтобы данное действие могло завершиться; a rank s-complete — множество номеров процессов, которые завершают действие (всегда один элемент — номер текущего процесса).
Вышеприведенные понятия рассматривают набор действий в нескольких ветвях параллельной программы как отражение одной MPI-операции в трассе программы. Такие действия можно найти по одинаковому передаваемому вместе с сообщением таймеру Т. Эти отношения определяются таким образом, что для множества действий Ет, соответствующего одной MPI-операции, идентифицируемой передаваемым значением таймера Т, выполняется следующее условие:
У starts(e)i = У completes(e)i и [^J starts(e)2 = ^J completes(е)2.
еЕ-Ет еЕ-Ет еЕ-Ет е£Ет
В таблице приведены примеры значения данных функций для различных действий MPI, в ней были использованы следующие обозначения:
t — номер процесса, в котором произошло действие;
comm — множество номеров процессов, входящих в коммуникатор (групповой) операции; root — номер выделенного процесса в групповой операции.
Действие Участвующие процессы Значение функции starts(e) Значение функции completes (e)
MPI.Send t^j m, ш) (0,0)
MPI_Recv i -»■ t (0,0) ({«•}- it})
MPI_Bcast root —ï comm \ {root} если t = root: ({root}, comm \ {root}), иначе (0, 0) если t ф root: ({root},{t}), иначе (0,0)
MPI_Barrier [comm] -O- [comm] ({t}, comm) (comm, {t})
Утверждение 4. Рассмотрим набор действий Е = {(ех, ё\), (в2, ¿2),..., е&)}. Множество действий, предшествующих данному набору, Е = {е^ : ё{ ^ е^, Е {1,...,/г}}, где ё{ — одно из действий процесса с номером г. Рассмотрим множество Т — множество значений таймеров, переданных вместе с сообщениями действий из множества Е. Если ЗТ 6 Т такое, что для всех ер из Е, для которых переданным значением таймера было Т, выполнено одно из двух условий:
(1)
У starts(ep)2J ф ^(J completes(ер)2 ], У completes(ep)i^ П {1,..., к} ф 0
У starts(ep)iJ ф completes(ep)i j, (Jstarts(ep)2 ) П {1,..., к} ф 0,
(2)
то набор действий Е не может входить ни в одно возможное место создания контрольной точки.
Доказательство. Рассмотрим случай нарушения условия (1), в случае невыполнения условия (2) доказательство аналогичное. Пусть нашелся Т, удовлетворяющий условиям утверждения. Тогда этому значению таймера соответствует одна MPI-операция, а ей в свою очередь соответствует множество действий Е из трассы параллельной программы. Докажем, что Е Е: из первой части условия (1) и определения функций completes и starts следует, что не все действия из группы, соответствующей MPI-операции с передаваемым таймером Т, вошли в множество Е, а значит, Е Е. Из второй
части условия (1) следует, что один из процессов, который начинает рассматриваемую MPI-операцию, имеет номер от 1 до к. Из этих двух наблюдений следует, что процесс с номером от 1 до к совершил соответствующее началу операции действие в момент, следующий за набором действий Е, а это значит, что для любого набора действий, включающего Е, контрольная точка создана быть не может (выбор мест создания KT в оставшихся п — к ветвях не повлияет на завершенность операции).
Алгоритм 2. Поиск возможных мест создания консистентных контрольных точек с использованием трассы MPI-программы (улучшенный переборный алгоритм).
1. Последовательно перебираются промежутки между парами детерминированных действий в 1-й ветви: (ei,êi). После этого рекурсивно осуществляется перебор промежутков для 2-й ветви, для 3-й и т.д.
2. Каждый частичный набор промежутков (ei, ег, • • • проверяется на соответствие утверждениям 3 и 4. Если текущий выбор не удовлетворяет условиям утверждений, выбор в текущей ветви отменяется, спуск к следующей ветви не происходит (как бесперспективный) и выбирается следующий промежуток в текущей ветви.
5. Заключение. На данный момент остается открытым вопрос о NP-полноте задачи поиска консистентных мест созданий контрольных точек (или о существовании полиномиального алгоритма ее решения). Для анализа групповых действий MPI используется моделирование этих операций через группу операций точка-точка, которые накладывают эквивалентные причинно-следственные зависимости.
Данный подход имеет ограничения по классу задач, к которым он может быть применен (неизменность или контролируемая зависимость трассы программы от входных данных, предположения о детерминированности программы), однако он позволяет выявить места создания контрольных точек в неочевидных для программиста ситуациях, может быть использован для проверки ручной расстановки контрольных точек.
СПИСОК ЛИТЕРАТУРЫ
1. Машечкин И. В.,Попов И. С.,Смирнов A.A. Система консистентных контрольных точек для кластерных вычислительных систем // Методы и средства обработки информации. Труды второй Всероссийской научной конференции. М.: Изд. отдел ф-та ВМиК МГУ, 2005. С. 400-406.
2. Машечкин И. В., Попов И. С., Смирнов A.A. Автоматизированная библиотека контрольных точек для кластерных вычислительных систем // Программные системы и инструменты. № 5. М.: Изд. отдел ф-та ВМиК МГУ, 2004. С. 40-50.
3. Lamport L. Times, clocks, and the ordering of events in a distributed system // Communications of the ACM. 1978. 21. N 7. P. 558-565.
4. Fidge C.J. Partial orders for parallel debugging // Proc. of the 1988 ACM SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging. N.Y.: ACM Press, 1989. P. 183-194.
5. Netzer R. H.B., Miller B.P. Optimal tracing and replay for debugging message-passing parallel programs // Proc. of 1992 ACM/IEEE Conf. on Supercomputing. Los Alamitos: IEEE Computer Society Press, 1992. P. 502-511.
Поступила в редакцию 27.11.06
