Проектирование параллельных алгоритмов в задачах идентификации. Вашкевич Н.П - 16 стр.

UptoLike

1
6
временным затратам нужно учитывать и стоимость создания задачи на процессоре ( вы-
деление памяти и т.д.).
Исходя из вышесказанного, объединение взаимодействующих задач в одну устраня-
ет необходимость их внешних коммуникаций, так как полученная задача будет выпол-
няться на одном процессоре.
Можно отметить, что при разбиении по данным эффективен подход увеличения ло-
кальности за счет увеличении размерности "куска", обрабатываемых регулярных данных
(векторы, матрицы и т.п.). Но если данные нерегулярны то задача агломерации становит-
ся достаточно трудной.
Можно попытаться использовать размножение данных и/или операций для сокра-
щения коммуникаций и/или для сокращения времени вычисления.
Сохранение гибкости. Хорошо разработанный параллельный алгоритм должен
быть гибким по отношению к числу процессоров в системе, что повышает ее надежность
в целом. Эта гибкость также полезна и когда создается код для отдельного процессора.
Если задачи часто блокируются в ожидании удаленных данных это может быть благопри-
ятным при назначении нескольких таких задач на один процессор, с тем что пока одна
задача ожидает данных другая может выполняться на ее месте. И тогда время коммуни-
кации перекрывается вычислением т.е. процессор не простаивает (техника перекрытий
вычислений и коммуникаций). Третья полезность создания большего числа задач чем
процессоров состоит в обеспечении лучших возможностей при распределении задач по
процессорам ( балансировка вычислений ). Хорошее правило состоит в том, что число за-
дач на порядок больше числа процессоров.
Оптимальное число задач обычно определяется комбинацией аналитического моде-
лирования и эмпирического изучения.
Сокращение инженерной стоимости софта. До сих пор предполагалось, что вы-
бор стратегии агломерации определялся только улучшением скорости вычислений и гиб-
костью параллельного алгоритма. Если на этом этапе удастся получить идентичные зада-
чи ( несколько или все ) то при технической реализации алгоритма можно получить
большую экономию как по времени, так и по трудовым затратам при разработке машин-
ных кодов задач.
Результаты этапа разработки коммуникаций необходимо сверить со следующими кон-
трольными вопросами.
1) Уменьшаются ли затраты времени на коммуникации при увеличении локальности?
Если нет то надо искать другую стратегию.
2) Если агломерация размножает вычисления, то нужно проверить, что польза от раз-
множения перевешивает затраты по отношению к росту размерности задачи и числу
процессоров.
3) Если агломерация размножает данные проверьте, что это не компрометирует мас-
штабируемость вашего алгоритма, ограничивая размер задачи или число используе-
мых процессоров.
временным затратам нужно учитывать и стоимость создания задачи на процессоре ( вы-
деление памяти и т.д.).
      Исходя из вышесказанного, объединение взаимодействующих задач в одну устраня-
ет необходимость их внешних коммуникаций, так как полученная задача будет выпол-
няться на одном процессоре.
      Можно отметить, что при разбиении по данным эффективен подход увеличения ло-
кальности за счет увеличении размерности "куска", обрабатываемых регулярных данных
(векторы, матрицы и т.п.). Но если данные нерегулярны то задача агломерации становит-
ся достаточно трудной.
      Можно попытаться использовать размножение данных и/или операций для сокра-
щения коммуникаций и/или для сокращения времени вычисления.
      Сохранение гибкости. Хорошо разработанный параллельный алгоритм должен
быть гибким по отношению к числу процессоров в системе, что повышает ее надежность
в целом. Эта гибкость также полезна и когда создается код для отдельного процессора.
Если задачи часто блокируются в ожидании удаленных данных это может быть благопри-
ятным при назначении нескольких таких задач на один процессор, с тем что пока одна
задача ожидает данных другая может выполняться на ее месте. И тогда время коммуни-
кации перекрывается вычислением т.е. процессор не простаивает (техника перекрытий
вычислений и коммуникаций). Третья полезность создания большего числа задач чем
процессоров состоит в обеспечении лучших возможностей при распределении задач по
процессорам ( балансировка вычислений ). Хорошее правило состоит в том, что число за-
дач на порядок больше числа процессоров.
      Оптимальное число задач обычно определяется комбинацией аналитического моде-
лирования и эмпирического изучения.
      Сокращение инженерной стоимости софта. До сих пор предполагалось, что вы-
бор стратегии агломерации определялся только улучшением скорости вычислений и гиб-
костью параллельного алгоритма. Если на этом этапе удастся получить идентичные зада-
чи ( несколько или все ) то при технической реализации алгоритма можно получить
большую экономию как по времени, так и по трудовым затратам при разработке машин-
ных кодов задач.
   Результаты этапа разработки коммуникаций необходимо сверить со следующими кон-
трольными вопросами.
   1) Уменьшаются ли затраты времени на коммуникации при увеличении локальности?
   Если нет то надо искать другую стратегию.

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

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




                                         16