CC BY
36
При создании систем бинокулярной визуализации виртуальной 3Б-среды нового поколения необходимо использовать модель, более полную по сравнению общепринятой моделью «стереого-ловы» с 6-ю степенями свободы (6-DOF, [2,3]). Эти системы могут использоваться как средство информационной поддержки в сложных операциях, для космических, навигационных, тренажерных и других систем, в которых необходима высокоточная совмещенная визуализация реальной и виртуальной сред.
Список литературы
1. Хилл Ф. OpenGL. Программирование компьютерной графики. - СПб.:Питер,2002.- 1088 с.
2. Jiang B., You S., Neumann U. A Robust Tracking System for Outdoor Augmented Reality, IEEE Virtual Reality 2004, Chicago, pp. 3 - 10, March 27-31, 2004.
3. Lee J.W, Neumann U. Motion Estimation with Incomplete Information using Omnidirectional Vision. IEEE International Conference on Image Processing (ICIP'00), Vol. 2, pp. 562-565, Vancouver Canada, September 2000.
4. Кравков С.В. Глаз и его работа. - М. - Л.: Изд-во. АН СССР. - 1950.
5. Шульговский В.В. Основы нейрофизилогии: Учебное пособие.-М.: Аспект Пресс, 2002.-277 с.
6. Марр Д. Зрение. Информационный подход к изучению представления и обработки зрительных образов.-М.: Радио и связь, 1987.
7. Литвак И.И., Ломов Б.Ф., Соловейчик И.Е. Основы построения аппаратуры отображения в автоматизированных системах. - М.: Советское радио, 1975.
8. Степанов Б.И. Введение в современную оптику. О возможном и невозможном в оптике. - Мн.: Наука и техника, 1989.-254 с.
9. Ландсберг Г.С. Оптика. - М.: Наука, 1976. - 928с.
10. Ермаков С.М., Бродский В.З. и др. Математическая теория планирования эксперимента. - М.: Наука, 1983. - 392 с.
11. Burdea G., Coiffet P. Virtual Reality Technology. - New York: John Wiley&Sons, Inc, 1994.
12. Helsel S.K. (Ed.). Beyond the vision. The technology, research and businnes of virtual reality. Meckler, London, 1992.
13. «Жидкая линза» для мобильных устройств. - Пресс-релиз hpc.ru (10 марта 2004).
14. Катыс Г.П., Катыс П.Г., Яковлев А.И. Трехмерные системы представления объемной информации. - М.: СИП РИА, 1998. - 112 с.
15. Михайлюк М.В., Решетников В.Н., Хураськин И.А. Технология взаимодействия человека с виртуальной средой. // Программные продукты и системы. - 2004. - № 2. - С. 16-19.
ПОДДЕРЖКА АППАРАТА КОНТРОЛЬНЫХ ТОЧЕК В КЛАСТЕРНЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМАХ
(Работа выполнена при поддержке Российского фонда фундаментальных исследований, проект № 02-01-00261)
И.В. Машечкин, И.С. Попов, А.А. Смирнов
Для решения больших вычислительных задач, к числу которых можно отнести задачи из таких областей, как предсказание погоды, биология, физика, астрономия и другие, требуются высокопроизводительные вычислительные системы. Производительность последовательного компьютера имеет свои пределы и существенно увеличить ее не удается. В такой ситуации на помощь приходят параллельные вычислители, которые по своей производительности могут значительно превосходить последовательные. Однако написание программ для параллельных вычислителей является отдельной задачей, решением которой занимается параллельное программирование. При написании параллельных программ принимается некоторая модель параллельных вычислений, одной которых является модель обмена сообщениями. В этой модели единственным способом взаимодействия ветвей параллельной задачи является обмен сообщениями между ними. Широко используемым стандартом на интерфейс обмена сообщениями является стандарт MPI [2]. Наиболее часто такие вычислительные системы обладают кластерной архитектурой.
Контрольная точка - информация о состоянии задачи, которая позволяет продолжить ее выполнение с некоторого момента времени. Основной целью применения механизма контрольных
точек является повышение эффективности использования кластерного времени. Такое повышение эффективности может быть достигнуто путем повышения отказоустойчивости вычислительных задач [1], а также путем обеспечения большей гибкости планирования для системы управления заданиями. В первом случае периодически создаваемые контрольные точки задачи позволяют свести к минимуму потери при сбое в кластере. Во втором случае механизм контрольных точек предоставляет системе управления заданиями возможность временно снимать со счета длительные вычислительные задачи, освобождая ресурсы для задач с более коротким временем счета, а затем путем восстановления из контрольной точки продолжать выполнение длительных задач (при этом возможна ситуация, при которой задача будет восстановлена и продолжит работу на другом наборе узлов по сравнению с тем набором, на котором она была запущена изначально). Также в ситуации, когда длительные задачи прерываются на время в пользу более коротких, может улучшаться качество обслуживания пользователей вычислительной системы, если под улучшением понимать минимизацию времени, которое задача проводит в очереди готовых к запуску при незначительном увеличении времени счета других задач.
При применении механизма контрольных точек для параллельных задач в системе обмена сообщениями возникают особые проблемы, не свойственные системам контрольных точек для последовательных задач. Дело в том, что параллельная задача в этом случае представляет собой множество ветвей, каждая из которых реализована в виде независимого процесса, а единственным способом взаимодействия ветвей является обмен сообщениями через некоторую общую коммуникационную среду. Возможны ситуации, при которых даже корректное восстановление состояния всех ветвей задачи приведет к некорректному продолжению вычислений, что может быть связано с потерей или дублированием сообщений в коммуникационной среде.
Кроме проблемы обеспечения корректности восстановления для параллельных задач, актуальной является задача повышения эффективности механизма контрольных точек, то есть уменьшение издержек на создание контрольной точки и восстановление из нее. Очевидно, что контрольные точки должны быть реализованы таким образом, чтобы их применение не оказывало существенного влияния на время выполнения задачи, однако объем контрольной точки параллельной задачи примерно равен произведению количества ветвей на объем памяти, которая необходима каждой ветви. Таким образом, при большом уровне параллельности и высоких требований задачи к памяти объем контрольной точки может составлять десятки гигабайт, и передача такого количества данных на какой-либо носитель может потребовать значительного количества времени, что неизбежно приведет к задержкам в выполнении исходной задачи. Следовательно, проблеме повышения эффективности должно уделяться особое внимание при проектировании и разработке систем контрольных точек.
Теоретические аспекты реализации механизма контрольных точек
Все механизмы контрольных точек по способу реализации можно разделить на пользовательские и автоматические. В случае применения первого подхода программист для каждой задачи реализует механизм контрольных точек с нуля, полностью решая задачу сохранения и корректного восстановления состояния задачи. Автоматические контрольные точки реализуются на уровне операционной системы или на уровне библиотеки программирования; такая реализация предлагает услуги по созданию контрольных точек для широкого класса задач, требуя от программиста внесения минимальных изменений в исходный код задачи. Реализация на уровне операционной системы (в виде модуля ядра системы) позволяет более полно сохранять и восстанавливать состояния процесса, однако такая реализация предполагает относительно низкую переносимость (система контроль-
ных точек обращается к структурам данных ядра ОС, которые подвержены частым изменениям) и требует прав администратора при внедрении; реализация же в виде библиотеки, которая работает на уровне процесса пользователя, использует менее подверженные изменениям интерфейсы и не требует участия администратора в процессе внедрения, однако позволяет сохранить лишь подмножество состояния процесса, которого, однако, оказывается достаточно для большинства вычислительных задач. Если же сравнивать пользовательские и автоматические контрольные точки, то можно сказать, что пользовательские контрольные точки обычно являются более эффективным механизмом, так как их реализация может учитывать специфические особенности конкретной задачи, однако необходимость реализации для каждой задачи является серьезным недостатком. Автоматические контрольные точки в общем случае могут предложить более низкую эффективность, но это может компенсироваться общностью подхода.
Как уже упоминалось ранее, чаще всего параллельные задачи в кластерных вычислительных системах взаимодействуют при помощи обмена сообщениями через общую коммуникационную среду, которой в кластерах является сеть либо специализированная (такая, как Myrinet, SCI), либо обычная (например, Fast Ethernet). Это означает, что в состояние параллельной задачи (а значит, и в контрольную точку этой задачи) входит, кроме состояния каждой ее ветви как отдельного процесса, еще и состояние коммуникационной среды. Обычно состояние коммуникационной среды (сообщения, которые могли в ней находиться в момент создания контрольной точки) не сохраняется, так как его сохранение и восстановление потребует значительных усилий, вместо этого вводятся ограничения на это состояние.
Рассмотрим пример, приведенный на рисунке
1.
С'
Р1
Р2 Рз
На рисунке показаны три ветви параллельно задачи Р, которые взаимодействуют при помощи отправки сообщений т. Горизонтальные линии соответствуют времени в каждой ветви, кружочками отображены моменты создания контрольных точек. Так, при восстановлении из контрольной точки С будет потеряно сообщение т2, а при восстановлении из контрольной точки С' будет потеряно т2 и продублировано сообщение т3. Таким образом, при восстановлении возможны два типа ошибок - потеря и дублирование сообщений, обе
С
эти ошибки для вычислительных задач приведут к некорректному продолжению вычислений (в других применениях в случае взаимодействующих при помощи сообщений приложений цена потери и дублирования может быть разной). Поэтому будем называть в дальнейшем контрольную точку вычислительной задачи консистентной, если в момент ее создания не было обменов сообщениями, то есть все отправленные сообщения были получены, и в каналах связи не было сообщений. Во всех других случаях контрольная точка будет называться неконсистентной.
Существует два классических алгоритма обеспечения консистентности: синхронные и асинхронные контрольные точки. В первом случае происходит инициализация процедуры создания контрольной точки в одной из ветвей, которая отправляет служебное сообщение всем остальным ветвям: «Готовьтесь к созданию контрольной точки». После получения такого сообщения ветви прекращают отправлять сообщения, за исключением служебных, но продолжают принимать сообщения. Затем, когда все ветви убеждаются в том, что коммуникационные каналы пусты (например, при помощи тестовых сообщений), они сообщают о своей готовности ветви-инициатору. Как только все ветви готовы к созданию контрольной точки, они одновременно начинают создавать свои контрольные точки. После того как создание контрольных точек завершено, выполнение параллельной задачи продолжается.
Асинхронные контрольные точки создаются в ветвях задачи в произвольные моменты времени, причем в каждой ветви независимо. При этом пропадает всякая необходимость в синхронизации процессов, однако получение консистентной контрольной точки из набора контрольных точек ветвей не всегда является тривиальной задачей. При таком подходе требуется хранить несколько (а иногда и все) контрольные точки для каждой ветви. Поиск консистентного состояния на наборах контрольных точек является задачей отдельного алгоритма, но при его использовании возможны ситуации, когда ни одна комбинация контрольных точек отдельных ветвей не образует консистентного состояния (эффект домино).
Рассмотрим еще один подход: предварительная синхронизация, гарантирующая консистент-ность контрольной точки. В этом случае в исходном коде задачи заранее размещаются подсказки для системы контрольных точек, которые говорят о том, в какой именно момент ветви параллельной задачи находятся в таком состоянии, что их контрольные точки будут образовывать консистентное состояние. Выбор места синхронизации основывается на следующих критериях:
• коммуникационные каналы пусты;
• никакой процесс не заблокирован в состоянии получения сообщения.
Эти условия, очевидно, гарантируют конси-стентность контрольной точки, так как ни одно сообщение не будет потеряно (первое условие) и все процессы готовы к созданию контрольной точки (второе условие). Такие точки синхронизации обычно располагаются в конце какой-то итерации вычислений, после выполнения групповых операций MPI, которые затрагивают все ветви задачи. Данный подход за счет предварительного выбора предполагает минимальные временные затраты на синхронизацию ветвей задачи перед созданием контрольной точки.
Для осуществления выбора места синхронизации может быть предложено несколько методов:
- ручной выбор программистом;
- статический анализ программы (места синхронизации выявляются на этапе компиляции);
- динамический анализ программы (выполняется несколько тестовых прогонов программы, во время которых обнаруживаются самые удачные точки синхронизации).
Под повышением эффективности системы контрольных точек понимают уменьшение издержек на создание контрольной точки и восстановление из нее. Основная часть издержек при создании контрольной точки связана с записью данных на диск, а объем записываемых данных можно оценить объемом памяти, используемым параллельной задачей (суммарным объемом данных всех ее ветвей). Издержки на восстановление из контрольной точки связаны с чтением того же объема данных, дополнительными процедурами при восстановлении, но все же большая часть издержек связана с вводом-выводом. Следовательно, повышение эффективности можно ожидать при уменьшении издержек на чтение и запись данных на диск (или на файловый сервер, в зависимости от конфигурации кластера), а также при уменьшении самого объема данных, который необходимо записать. Рассмотрим несколько методов повышения эффективности механизма контрольных точек [3-4].
Сжатие данных. Так как контрольная точка содержит данные процесса, а они достаточно хорошо сжимаются (в предположении об избыточности данных), то применение алгоритма сжатия к содержимому контрольной точки позволяет значительно уменьшить ее размер. Однако так как цель состоит также в уменьшении задержек на время создания контрольной точки, необходимо выбирать алгоритмы, которые бы обеспечивали приемлемые коэффициенты сжатия, но при этом не требовали большого количества процессорного времени. Такой компромисс можно найти в семействе алгоритмов словарного сжатия. Если заранее известен характер данных задачи, можно применять специализированные алгоритмы сжатия, которые бы позволили достичь более качественных результатов на конкретных задачах.
Обычный процесс создания контрольной точки имеет существенный недостаток: выполнение процесса прерывается на время создания контрольной точки. В случае асинхронной контрольной точки выполнение задачи не прерывается, а создание контрольной точки ведется в фоновом режиме, однако, так как требуется сохранить состояние процесса на момент создания контрольной точки, необходимо каким-то образом сохранить это состояние. В ОС семейства UNIX сохранение состояния может быть достигнуто экономным способом, при помощи системного вызова fork(). Так как создание контрольной точки - это в основном ввод-вывод, а самой вычислительной задаче требуется время ЦП, то эти операции можно выполнять параллельно без потери производительности.
Еще одним способом повышения эффективности является исключение ненужных областей памяти из контрольной точки. Этот способ является актуальным, если после создания контрольной точки задача первой операцией обращается к некоторым достаточно большим областям памяти на запись, а не на чтения. В такой ситуации нет необходимости включать эти области памяти в контрольную точку, так как после восстановления сохраненные значения не будут использованы. Примером таких областей памяти могут служить временные массивы данных, используемые задачей на каждой итерации вычислений, при условии, что контрольная точка создается в конце итерации.
Экспериментальная реализация: libcheckpoint
В результате анализа существующих решений, а также исследования различных подходов к реализации систем контрольных точек был выбран следующий подход: библиотека автоматических контрольных точек на уровне процесса пользователя ОС семейства UNIX. Такая реализация предполагает простоту внедрения (не требуется вмешательства системного администратора), легкость использования (требуется лишь внесение минимальных изменений в существующие программы) и высокую переносимость. Выбор класса операционных систем связан с тем, что операционные системы этого семейства чаще всего используются при построении кластеров (в частности, ОС Linux). Так же был осуществлен выбор коммуникационных сред:
• разделяемая память (чистые SMP-системы);
• сеть Myrinet (коммуникационная среда многих высокопроизводительных кластеров).
Была выбрана конкретная реализация MPI -MPICH, так как она является наиболее распро-
страненной реализацией MPI (MPICH, например, используется в МВС-1000М). Был осуществлен выбор метода обеспечения консистентности контрольной точки - предварительная синхронизация. Данный метод позволяет обеспечить низкие задержки на синхронизацию ветвей, требует хранения лишь одного набора контрольных точек ветвей и его реализация не приводит к изменению структуры обмена сообщений задачи (не требует применения служебных сообщений). В библиотеке были реализованы три наиболее применимых метода повышения эффективности: сжатие данных, асинхронные контрольные точки и исключение ненужных областей данных из контрольной точки.
При проектировании и разработке преследовалось несколько основных целей:
• переносимость;
• отсутствие необходимости внесения изменений в системные библиотеки и библиотеки MPICH (или необходимость минимальных изменений);
• настройка на конечную архитектуру на этапе компиляции;
• максимальная эффективность при сохранении корректности сохранения состояния задачи.
Основными характеристикам библиотеки являются:
- реализация автоматических контрольных точек на уровне процесса пользователя (сама библиотека libcheckpoint написана на языке C);
- поддержка различных архитектур:
o FreeBSD/x86,
o Linux/x86,
o Linux/Alpha;
- поддерживаемые языки программирования: o С/С++,
o Fortran;
- сохранение состояния процесса (сегмент данных, стек, куча, контекст процесса);
- сохранение состояния операционной системы (отображения в память (mmap/munmap), открытые файлы (open/close/lseek/read/write/...), обработчики сигналов);
- миграция процессов между машинами с идентичной архитектурой (восстановление задачи на другом наборе узлов по сравнению с тем, на котором она работала до создания контрольной точки);
- получение информации об эффективности работы библиотеки.
Архитектура библиотеки
Архитектуру библиотеки можно отобразить на схеме (рис. 2).
Интерфейс с библиотекой МР1СН, поддержка контрольных точек для параллельных задач
Перехват обращений к библиотечным вызовам
Определение расположения различных областей процесса
Поддержка списка областей адресного пространства процесса
Подсистема сжатия контрольных точек
Подсистема чтения/записи файлов контрольных точек
Рис. 2
На схеме отображены подсистемы библиотеки, каждый вышележащий слой использует сервисы, предоставляемые слоем, находящимся ниже по уровню. Верхняя подсистема, интерфейс с библиотекой МР1СН, помечена пунктирной линией, так как ее наличие не является обязательной. Без нее получается библиотека контрольных точек для одного процесса, а с ней - библиотека контрольных точек для параллельных задач. Теперь поподробнее о каждой из подсистем.
• Подсистема чтения/записи файлов контрольных точек отвечает за формирование файла контрольный точек, который состоит из заголовка и информации о каждой сохраненной области памяти (ее тип, размер, начальный адрес и содержимое). Эта подсистема также отвечает за нумерацию файлов контрольных точек.
• Подсистема сжатия контрольных точек отвечает за сжатие содержимого сохраняемых областей памяти. Сжатие используется для уменьшения размера контрольной точки. Данная подсистема может быть полностью отключена при настройке библиотеки.
• Подсистема поддержки списка областей адресного пространства обеспечивает изменение, сохранение и восстановление списка областей адресного пространства, которые необходимо включить или исключить из контрольной точки. Данный список может модифицироваться как другими подсистемами библиотеки, так и пользователем через специальный интерфейс (чтобы обеспечить возможность программисту исключать ненужные области памяти из контрольной точки).
• Подсистема определения расположения различных областей процесса инициализирует и поддерживает список областей адресного пространства процесса, внося туда информацию о расположении сегмента данных, стека и кучи процесса.
• Подсистема перехвата обращений к библиотечным вызовам позволяет библиотеке запоминать информацию обо всех системных ресурсах, используемых процессом. Информация о ресурсах заносится в специальные таблицы и используется при восстановлении, также может мо-
дифицироваться список областей адресного пространства процесса (например, при выделении и освобождении отображений в память).
• Подсистема интерфейса с библиотекой МР1СН обеспечивает синхронизацию, корректное сохранение и восстановление состояния библиотеки обмена сообщениями при создании и восстановлении из контрольной точки.
Из неотображенных на схеме подсистем необходимо упомянуть подсистему сбора информации об эффективности библиотеки, которая сохраняет информацию о продолжительности работы различных этапов работы библиотеки (создание контрольной точки, восстановление из контрольной точки, синхронизация).
Рассмотрим некоторые аспекты реализации библиотеки.
Передача управления при работе библиотеки
При запуске программы без восстановления из контрольной точки схема передачи управления между программой и библиотекой контрольных точек выглядит следующим образом (рис. 3).
program.c libcheckpoint
int main(int агдс, ...)
скр^та1п (агдс, { рг1^("Ие11о 1\п") ; ckptCheckpoint(); скр^п^ ( ) ; ^^^^скр^та^ ( агдс, ...) ckptDone();
printf("He11o 2\п"); ге'Ьигп 0; } int ckptCheckpoint() { /* . . . */ }
Рис. 3
После запуска программы управление передается в функцию шаш(), которая находится в библиотеке ИЪсНескроШ. В случае если использование библиотеки не было запрещено при помощи конфигурационного файла, вызывается функция скрйпЫ(), которая кроме всего прочего проверяет наличие контрольной точки программы. Если контрольная точка не была найдена, управление передается в функцию скрг_шат(), которая уже находится в основной программе. После этого основная программа в какой-то момент может вызывать функцию создания контрольной точки, скрСкескроШ(), которая сохранит контрольную точку и вернет управление обратно в программу.
При восстановлении последовательность вызовов изменяется (рис. 4).
Функция скрйпЫ() обнаруживает наличие контрольной точки и вызывает функцию ckptRestore(), которая в конце восстановления вызывает библиотечную функцию ¡оп^шр(), которая уже передает управление основной программе в точку, соответствующую возврату из функции скрСкескроШ(), после чего выполнение продол-
program.c libcheckpoint
int ckpt_main(int argc, ...) { printf("Hello 1\n"); ckptCheckpoint(); printf ("Hello 2\n^^s return 0; 1 int main (int argc, ...) { ckptlnit(); ckpt_main (argc, ...) ckptDone(); 1 int ckptRestore() < /****/ longjmp(---); 1
Рис. 4
жается (данная схема несколько упрощена по сравнению с реальной последовательностью вызовов).
Результаты тестирования эффективности
Для тестирования эффективности библиотеки была выбрана вычислительная задача расчета сво-бодномолекулярного обтекания цилиндра, написанная на языке ЕотЧтап-П. Тестирование производилось на суперЭВМ МВС-1000М, программа запускалась в штатном режиме работы суперкомпьютера, поэтому на приведенные результаты существенное влияние могла оказать загруженность файлового сервера, связанная с работой других задач. Библиотека контрольных точек была сконфигурирована с использованием подсистемы сжатия. Измерения проводились при помощи встроенных в библиотеку средств, в каждом эксперименте задача создавала 10 контрольных точек на протяжении своей работы, после этого временные затраты усреднялись. В этом тестировании не использовались никакие методы повышения эффективности, за исключением сжатия данных контрольных точки.
Полученные результаты отражены в таблице.
Таблица
Из полученных результатов следует, что в среднем издержки на создание контрольной точки такой задачи составляют 9,35 секунды, что при интервале создания контрольных точек в 30 минут составляет 0,5% потери по времени. Коэффициент сжатия данных контрольной точки в данном эксперименте достигал 43%.
Среднее время восстановления задачи составляет около 15 секунд, что является вполне приемлемым.
На основе проведенных исследований была выполнена экспериментальная реализация библиотеки автоматических контрольных точек для параллельных задач в системе обмена сообщениями. Предлагаемая реализация поддерживает библиотеку обмена сообщениями MPICH в двух коммуникационных средах: разделяемая память (SMP-узлы) и сеть Myrinet (используется в кластерных системах, например, МВС-1000М).
Одной из целей при разработке являлось обеспечение переносимости полученной библиотеки: так, поддерживаются следующие архитектуры вычислительных систем: FreeBSD/x86, Linux/x86, Linux/Alpha. К библиотеке разработан интерфейс для языков C/C++ и Fortran, то есть она может быть использована в вычислительных задачах, написанных на этих языках. В перспективе могут быть разработаны интерфейсы для других языков программирования.
Библиотека полностью сохраняет состояние процесса, из состояния операционной системы сохраняются только открытые файлы и отображения в память. Такого сохраненного состояния хватает для корректного восстановления выполнения большинства вычислительных задач.
Предложенная реализация не является единственной, существуют и другие реализации систем контрольных точек (например [3,8-lG]), однако они обладают рядом существенных недостатков, таких как отсутствие поддержки параллельных задач, малая переносимость и отсутствие поддержки MPICH. Необходимо упомянуть миграцию процессов - перенос работающего процесса с одной вычислительной системы на другую, причем эти системы могут иметь разную архитектуру. Миграция осуществляется путем создания контрольной точки (в случае разных архитектур - в особом формате), которая и перемещается между вычислительными системами [6-7].
Отметим возможные направления развития библиотеки.
1. Перенос библиотеки libcheckpoint на другие архитектуры вычислительных систем, в том числе и на другие коммуникационные среды (например, Fast Ethernet). Возможна адаптация к другим реализациям MPI (например, LAM/MPI).
2. Автоматический выбор места синхронизации, гарантирующего консистентность контрольной точки.
3. Автоматическое исключение ненужных областей памяти из контрольной точки [5].
Список литературы
1. Christine Morin, Isabelle Puaut. A Survey of Recoverable Distributed Shared Memory Systems. - IEEE Trans. on Parallel and Distributed Systems. - Volume 8. - Issue 9. - pp. 959-969. - 1997.
2. Message Passing Interface Forum. MPI: A Message-Passing Interface Standard. Version 1.1, June 1995.
3. James S. Plank, Micah Beck, Gerry Kingsley, Kai Li. Libckpt: Transparent Checkpointing under Unix. In Proceedings of the 1995 Winter USENIX Technical Conference. - UT-CS-94-242.
Кол-во ветвей Размер КТ одной ветви, Кб Общий размер КТ задачи, Кб Затраты на: Итого
создание КТ синхронизацию
4 52G63 2G8252 1G,84 G,51 11,34
1G 23292 23292G 7,68 G,67 8,35
2G 13854 277G8G 8,93 G,55 9,48
3G 957G 2871GG 9,11 G,51 9,62
4G 9234 36936G 7,35 G,6G 7,95
В среднем: 8,78 0,56 9,35
4. James S. Plank, Jian Xu, Robert H. B. Netzer. Compressed Differences: An Algorithm for Fast Incremental Checkpointing. Technical Report CS-95-302, University of Tennessee, August 1995.
5. James S. Plank, Micah Beck, Gerry Kingsley. CompilerAssisted Memory Exclusion for Fast Checkpointing. - IEEE Technical Committee on Operating Systems and Application Environments, Special Issue on Fault-Tolerance. - Winter 1995.
6. Peter Smith, Norman C. Hutchinson. Heterogeneous Process Migration: The Tui System. - Software Practice and Experience. - Volume 28. - Issue 6. - pp. 611-639. - 1998.
7. Adam J. Ferrari, Stephen J. Chapin, Andrew S. Grimshaw. Process Introspection: A Heterogeneous Checkpoint/Restart Mechanism Based on Automatic Code Modification. - CS-97-05. -1997.
8. Sriram Sankaran, Jeffrey M. Squyres, Brian Barrett, Andrew Lumsdaine, Jason Duell, Paul Hargrove, Eric Roman. Parallel Checkpoint/Restart for MPI Applications.
9. Duell J., Hargrove P. and Roman E. The Design and Implementation of Berkley Lab's Linux Checkpoint/Restart, 2002.
10.Абрамова В.А., Баранов А.В., Храмцов М.Ю. Библиотека интерфейсных вызовов (API) для организации контрольных точек (КТ) (Документация по ПО МВС-1000М).
ПРЕДМЕТНАЯ ОБЛАСТЬ, МОДЕЛИ И ЗАДАЧИ ФУНКЦИОНАЛЬНО-СТОИМОСТНОГО АНАЛИЗА
М.В. Силуянова
Повышение конкурентоспособности сложных технических объектов авиационной и ракетно-космической техники может быть достигнуто только на основе активного воздействия на процессы их создания и эксплуатации, включая все стадии и этапы жизненного цикла. Эффективные целенаправленные воздействия могут рассматриваться как процесс управления качеством и экономической эффективностью. Этот процесс включает такие этапы, как выявление показателей качества и технико-экономических показателей, установление влияния на них всех составляющих процессов проектирования, производства и эксплуатации и определения на основе анализа влияний управляющих воздействий.
Одна из сторон этой проблемы (состав и уровень показателей качества и экономической эффективности) определяется на основе анализа требований потребителей с учетом возможностей и достижений науки и техники.
Вторая сторона проблемы определяется возможностями технологии на производственных стадиях жизненного цикла изделий с учетом ресурсов конкретных предприятий.
Многочисленность показателей качества и факторов технологии и производства, сложность взаимодействия между ними и их взаимовлияния, наличие прямых и обратных связей и системы ограничений технического, технологического, организационного и экономического характера, а также необходимость оценки степени риска на этапе приятия решений определяют необходимость разработки и применения в процессах технологической подготовки производства методов системного и функционально-стоимостного анализа.
Проблема функционально-стоимостного анализа относится к числу слабо формализованных и слабоструктурированных проблем, потому что показатели качества и взаимосвязанные с ними технико-экономические показатели формируются
на различных стадиях жизненного цикла объектов в различных системах проектирования, производства и эксплуатации, что определяет существенные трудности ее решения.
Задачи функционально-стоимостного анализа можно разделить на два больших класса:
- детерминированные задачи, когда исходные данные, описывающие моделируемую ситуацию, являются полностью определенными;
- стохастические задачи, когда в исходной информации содержатся элементы неопределенности либо некоторые параметры носят случайный характер с известными вероятностными характеристиками.
Одна из главных трудностей решения стохастических задач состоит в самой постановке задач из-за сложности выявления и анализа значений и влияний различных факторов.
Модели формируются в темпе выполнения проектных и производственных работ, являются электронными макетами объектов и действуют всегда, а не только в период завершения работ. Модели функционально-стоимостного анализа структурированы, в процессе создания автономны и строятся по блочно-модульному принципу. Большая часть моделей создается параллельно с выполнением работ по проектированию и информационному сопровождению производства автоматизированными методами с использованием средств автоматизации сбора данных и проектирования.
Формирование и преобразование моделей функционально-стоимостного анализа выполняется в процедурно-алгоритмической среде, обеспечивающей выполнение взаимосвязанных проектных процедур и операций.
При этом для каждого структурного элемента изделия формируется и хранится конструктивное описание и для каждого варианта конструктивно-технологического решения технологическое и технико-экономическое описание. Технологиче-
