WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 | 2 || 4 | 5 |   ...   | 8 |

2) Каждая элементарная задача связана с небольшим числом соседей Если нет, то следует исследовать возможность преобразования глобальных коммуникаций в локальные.

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

4) Могут ли вычисления связанные с различными ЭЗ выполняться параллельно Если нет, то алгоритм также неэффективен и не масштабируем. Для устранения этого необходимо посмотреть, как переупорядочить операции и коммуникации, может быть даже вернувшись к постановке задачи.

2.3 Выбор модели аппаратной реализации параллельных вычислений На этом этапе необходимо определить наиболее подходящую модель аппаратной реализации параллельных алгоритмов из числа следующих: - сетка процессоров; - объединение процессоров через общую шину; - взаимодействие процессоров через общую память.

Р Р Р Р Р Р Рис. 2.1. Сетка процессоров E T H E R N E T Р Р Р Р Рис. 2.2. Объединение процессоров через шину Общая память Шина кэш кэш кэш Р Р Р Рис. 2.3. Взаимодействие процессоров через общую память 2.4 Выбор модели программной реализации параллельных вычислений На этом этапе необходимо определить наиболее подходящую модель программной реализации параллельных вычислений (задачи и каналы, пересылка сообщений с использованием стандартных библиотечных утилит, разделяемая память с использованием блокировок и семафоров).

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

В модели разделяемой памяти с использованием блокировок и семафоров задачи используют общее адресное пространство, в котором они читают и записывают данные асинхронно. Механизм блокировок и семафоров используется для контроля доступа к общей памяти 2.5 Объединение (агломерация) элементарных задач На этом этапе проектирования производится объединение (укрупнение) ЭЗ. После этапов разбиения и определения коммуникаций алгоритм, состоящий из ЭЗ является абстрактным в том смысле, что не может быть реализован на любой мультипроцессорной системе. Например он может быть малоприемлем, если создает очень много задач малого размера, а процессоры входящие в систему неэффективны при выполнении таких задач.

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

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

Три, как правило, взаимоконфликтующих цели преследуются при агломерации и размножении данных и/или операций:

- сокращение стоимости коммуникаций за счет объединения взаимосвязанных ЭЗ ( локализация коммуникаций );

- сохранение гибкости по отношению к масштабируемости ( изменению размерности задачи) и распределению задач по процессорам;

- сокращении стоимости инженерной разработки программного обеспечения ( софта ).

Рассмотрим каждую из них.

Локализация коммуникаций. На этапе разбиения алгоритма на ЭЗ усилия сосредотачивались на получении как можно большего числа задач. Это полезно, так как позволяет рассмотреть широкий круг возможностей удобных для параллельного выполнения.

Однако, следует заметить, что получение большого числа задач при разбиении не обязательно дает эффективный параллельный алгоритм. Самое негативное влияние на выполнение параллельного алгоритма ( по времени ), оказывают коммуникации. На большинстве параллельных систем приходится останавливать вычисления чтобы послать или принять сообщения. Поэтому значительно улучшится скорость вычисления, если сократить время на коммуникации. Ясно, что это можно достичь пересылкой меньшего объема данных между задачами, выполняющимися параллельно. Возможно менее очевидно, но сократить время на коммуникации можно и при использовании меньшего числа сообщений при тех же объемах данных. Это объясняется тем, что каждая коммуникация требует время не только пропорциональное объему пересылаемых данных, но имеет фиксированные начальные затраты времени по ее установлению. В дополнение к коммуникационным временным затратам нужно учитывать и стоимость создания задачи на процессоре ( выделение памяти и т.д.).

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

Можно отметить, что при разбиении по данным эффективен подход увеличения локальности за счет увеличении размерности "куска", обрабатываемых регулярных данных (векторы, матрицы и т.п.). Но если данные нерегулярны то задача агломерации становится достаточно трудной.

Можно попытаться использовать размножение данных и/или операций для сокращения коммуникаций и/или для сокращения времени вычисления.

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

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

Оптимальное число задач обычно определяется комбинацией аналитического моделирования и эмпирического изучения.

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

Результаты этапа разработки коммуникаций необходимо сверить со следующими контрольными вопросами.

1) Уменьшаются ли затраты времени на коммуникации при увеличении локальности Если нет то надо искать другую стратегию.

2) Если агломерация размножает вычисления, то нужно проверить, что польза от размножения перевешивает затраты по отношению к росту размерности задачи и числу процессоров.

3) Если агломерация размножает данные проверьте, что это не компрометирует масштабируемость вашего алгоритма, ограничивая размер задачи или число используемых процессоров.

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

5) Масштабируется ли число задач, получаемых при агломерации, с ростом входной размерности обрабатываемых данных. Если нет, то трудно использовать такой алгоритм с ростом размерности и числа процессоров.

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

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

2.6 Распределение задач по процессорам На заключительной стадии проектирования параллельного алгоритма нужно определить какая задача на каком процессоре будет выполняться. В целом задача распределения остается трудной задачей, которая должна быть точно разрешена при проектировании параллельного алгоритма. Цель распределения состоит в том чтобы минимизировать время выполнения алгоритма (сумма времен вычисления, простоя и коммуникаций ) и затраты памяти.

Используются две стратегии для достижения этой цели:

- размещение задач, которые могут выполняться параллельно на разных процессорах;

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

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

Такая задача распределения известна как NP-задача. Это означает, что задача трудно разрешима, поскольку для нее нет алгоритма решения с полиномиальной зависимостью от входной размерности (число задач и число процессоров). Поэтому при решении таких задач используются эвристические методы.

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

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

Наиболее сложным аспектом при составлении расписания является используемая стратегия при размещении задач по процессорам. В основном выбираемая стратегия представляет компромисс между конфликтными требованиями по независимости задач ( чтобы сократить стоимость коммуникаций ) и полном знании о состоянии вычислений ( чтобы улучшить балансировку загрузки процессоров ). Рассмотрим централизованный ( manager/workers ), иерархический ( manager/submanager/workers ) и децентрализованный подходы.

Централизованный подход. Manager ( управляющий ) отвечает за проблему размещения. Каждый worker ( исполнитель ) постоянно обращается к мanager с запросами ( например, сообщение об окончании выполнения задачи ) получает задачу от него и исполняет ее. В свою очередь workers могут послать новые задачи мanager, которые затем могут быть размещены по другим рабочим. Эффективность такой стратегии зависит от числа workers и относительной стоимости получения задач от manager и их выполнения. Результаты могут быть улучшены за счет перекрытия вычислений и коммуникаций, а также кешированием задач в workers так, чтобы workers связывались с мanager когда нет локальных ( своих ) задач.

Иерархический подход. Workers делятся на отдельные группы у которых свой submanager ( подуправляющий ). Workers из группы связываются только со своим submanager. Submanager периодически связываются с manager и другими submanager чтобы обеспечить балансировку загрузки процессоров за которые они отвечают.

Децентрализованный подход. В полностью децентрализованной схеме нет центрального управляющего. Соответственно отдельный пул задач назначается на каждый процессор и незанятые процессоры требуют задач от других процессоров. В результате пул задач становится распределенной структурой данных, которая доступна различным задачам асинхронно. При этом определяется какая-либо процедура доступа. Например worker может требовать задания только от небольшого числа соседей или выбирать другие процессоры по “заданному” случайному закону.

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

Доступ к распределенному пулу задач может быть получен несколькими способами.

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

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

Но это более сложная задача в децентрализованной схеме поскольку нет общей информации что процессоры закончили и требования на выполнение заданий будут "бродить" по системе.

Результаты этапа распределения необходимо сверить со следующими контрольными вопросами.

1) Если используется централизованная загрузочно-балансная схема, нужно проверить, что manager не является узким местом в системе. Также можно сократить коммуникационную стоимость в таких схемах передавая указатели на задачи а не сами задачи manager.

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

Pages:     | 1 | 2 || 4 | 5 |   ...   | 8 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.