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

UptoLike

19
стаивающие workers никогда не остановятся, требуя задания от других workers . Эта зада-
ча легко решается в централизованной схеме, где управляющий определяет, что все
workers закончили.
Но это более сложная задача в децентрализованной схеме поскольку нет общей ин-
формации что процессоры закончили и требования на выполнение заданий будут "бро-
дить" по системе.
Результаты этапа распределения необходимо сверить со следующими контрольными
вопросами.
1) Если используется централизованная загрузочно-балансная схема, нужно прове-
рить, что manager не является узким местом в системе. Также можно сократить ком-
муникационную стоимость в таких схемах передавая указатели на задачи а не сами
задачи manager.
2) Если используется централизованная загрузочно - балансная схема, нужно оценить,
относительную стоимость различных стратегий. Вероятностное или циклическое рас-
пределение задач является простым и должно быть также рассмотрено, так как это
поможет избежать необходимости в повторении загрузочно - балансировочных опера-
ций.
3) Если используются вероятностные или циклические методы есть ли достаточное
число задач для обеспечения балансировки при загрузке. Обычно для этого требуется
по крайней мере не менее 10 задач на процессор.
2.7 Анализ результатов проектирования.
Результатом проектирования будет один или несколько алгоритмов. Однако еще
нельзя начинать техническую реализацию алгоритма, так как несколько фаз в проектиро-
вании остаются. Во - первых нужно провести анализ, чтобы выбрать один из альтерна-
тивных алгоритмов, убедившись, что желаемые цели при проектировании достигнуты. Во
- вторых нужно внимательно подумать о начальной стоимости проектирования, о воз-
можностях переиспользования существующих кодов. В-третьих нужно исследовать как
поведут себя алгоритмы в больших системах, где они будут являться частью, для чего ин-
терполировать полученные результаты. При этом нужно оценить эффективность па-
раллельной реализации алгоритма как отношения времени
его выполнения при последо-
вательной реализации к времени выполнения при параллельной реализации, а также из-
менение его эффективности с ростом числа процессоров при неизменной размерности
исходных данных и изменение эффективности с ростом размерности исходных данных
при неизменности числа процессоров.
стаивающие workers никогда не остановятся, требуя задания от других workers . Эта зада-
ча легко решается в централизованной схеме, где управляющий определяет, что все
workers закончили.
   Но это более сложная задача в децентрализованной схеме поскольку нет общей ин-
формации что процессоры закончили и требования на выполнение заданий будут "бро-
дить" по системе.
   Результаты этапа распределения необходимо сверить со следующими контрольными
вопросами.
   1) Если используется централизованная загрузочно-балансная схема, нужно прове-
   рить, что manager не является узким местом в системе. Также можно сократить ком-
   муникационную стоимость в таких схемах передавая указатели на задачи а не сами
   задачи manager.

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

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

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




                                          19