PARALLEL.RU

Все клиенты имеют процесоры Athlon 1900, 512 mozgov, MB Tyan, IDE HDD 40gb

На мастере висит Fedora Core 2 + OSCAR 4.1

У меня вылетел один нод, интересно как изменится работоспособность кластера если вместо Атлоновских ЦПУ воткнуть интеловские ЦПУ. Интерересует вопрос о работоспособности kластера с разными процесорами.

Пасиба.

Будет работать без проблем, если только не мешать 32/64бит архитекруры (Athlon64 или Xeon EMT64 с обычными Athlon/Xeon). Будет разбалансировка приложений, но это не очень страшно, как правило.

Возьмите тот же линпак, да проверьте. Функция производительности от числа узлов зависит от задачи. Постройте кривую зависимости на задаче с ростом узлов и все увидите.

С точки зрения производительности разницы нет в случае "однорейтингового" железа.

Возможная проблема - архитектура. Если у вас программы для generic i686 то проблемм быть не должно. Желательно позаботиться и об идентичности сетевых плат.

Спасибо за оперативные ответы.

На мастере висит Fedora Core 2 + OSCAR 4.1
У меня вылетел один нод, интересно как изменится работоспособность кластера если вместо Атлоновских ЦПУ воткнуть интеловские ЦПУ. Интерересует вопрос о работоспособности kластера с разными процесорами.

в контексте параллельных вычислений:
производительность системы будет определятся производительностью слабого узла. неточная цитата из В.В.Воеводин, Вл.В.Воеводин - "Параллельные вычисления".

в практическом контексте: приложение собранное в одном рантайме в другом будет выполняться крайне неэффективно если будет выполняться вообще.

Guest.

Цитата на то и цитата, что бы быть точной. Иначе это Ваше умозаключение. А если скажем такая задача (а-ля Монте-Карло): нагенерировать как можно больше псевдослучайных чисел (как, например, EP из NPB), то Ваше утверждение ложно.


Утверждение крайне спорное. Если Вы сделаете статическую сборку интеловским компилятором версии 9.0 и запустите на машине с рантаймом в виде gcc 2.9... или 3.4... то этот код мало того, что выполниться, но и в зависимости от задачи покажет очень большое преимущество в скорости. Ну и в нормальных дистрибутивах для glib неплохая совместимость. Например, все что написано для RedHat 6 будет работать во всех последующих версиях этого дистрибутива.

Цитата на то и цитата, что бы быть точной. Иначе это Ваше умозаключение.

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

++++А если скажем такая задача (а-ля Монте-Карло): нагенерировать как можно больше псевдослучайных чисел (как, например, EP из NPB), то Ваше утверждение ложно.

Вы просто не заметили. на всякий случай повторю: "в контексте параллельных вычислений". А "а-ля Монте-Карло" или генерация псевдослучайных чисел есть задачи распределенные и на них заключение представленное в книге В.В Воеводин, Вл.В.Воеводин "Параллельные вычисления" не распространяется о чем говорится в той же книге.

+++Утверждение крайне спорное.

Спорное оно только на первый взляд...

З.Ы. Кстати, удивлен Вашим тоном...вы на что-то претендуете или это обычный стиль общения в данном форуме?

Guest

Ну мне просто не нравятся неточные цитаты. Они сбивают с толку.


В программах есть параллельная часть и последовательная. Ускорение в зависимости от числа узлов определяется законом Амдала. В показаной задаче последовательная часть равна 0... Такие задачи, по моему, это тоже контекст параллельных вычислений. А тест EP (построеный на этой задаче), на мой взгляд -- параллельная программа, широко используется для оценки верхней границы производительности паралелльных машин.

Еще пример. При сильных межузловых взаимодействиях. Узлы могут часть циклов работать в холостую. И разница между мощностью узлов будет "не видна" из за пропускной способностью и/или латентностью сети.

Определение производительности с-мы вопрос комплексный. И в наибольшей степени, на мой взгляд, зависит от задачи.


Разумеется есть некоторая несовместимость рантаймов. Да, кстати, что Вы понимаете под рантаймом. И приведите пример крайне неэффективного выполнения. У меня обычно либо выполняется с той скоростью которой должно, либо я просто не могу запустить программу X на платформе Y.


Это мой личный стиль общения. Я просто злой . Здесь обычно люди культурнее. Мне просто не очень нравяться безапеляционные утверждения, к которым хорошо бы добавить еще несколько НО...

+++Ну мне просто не нравятся неточные цитаты. Они сбивают с толку.

Да, мне тоже. но к сожалению дословно все трудно помнить...

++++В программах есть параллельная часть и последовательная. Ускорение в зависимости от числа узлов определяется законом Амдала. В показаной задаче последовательная часть равна 0... Такие задачи, по моему, это тоже контекст параллельных вычислений.

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

+++А тест EP (построеный на этой задаче), на мой взгляд -- параллельная программа, широко используется для оценки верхней границы производительности паралелльных машин.

Для оценки верхней границы производительности используется нехитрая формула:

кол.процессоров Х кол.оп.за такт Х тактовая частота

называется пиковая производительность


++++Еще пример. При сильных межузловых взаимодействиях. Узлы могут часть циклов работать в холостую. И разница между мощностью узлов будет "не видна" из за пропускной способностью и/или латентностью сети.

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

+++Определение производительности с-мы вопрос комплексный. И в наибольшей степени, на мой взгляд, зависит от задачи.

Да! Безусловно!


++++ Да, кстати, что Вы понимаете под рантаймом. И приведите пример крайне неэффективного выполнения. У меня обычно либо выполняется с той скоростью которой должно, либо я просто не могу запустить программу X на платформе Y.

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

ИМХО тоже справедливо и для процессоров разных производителей совместимых по командам но несовместимых по оптимизациям. Чтобы код работал эффективно необходим свой рантайм, ну например свой ATLAS, а лучше BLAS-GOTO. Что-то в там роде...

+++Это мой личный стиль общения.

ОК. буду иметь в виду.

на всякий случай, все написанное выше мое ИМХО

Олег.

Распределенные задачи, если Вы так настаиваете на этом термине, частный случай параллельных.


Это теоретическое понятие. А вот что даст Вам КОНКРЕТНАЯ система с КОНКРЕТНЫМ ПО на задачах без сетевого взаимодействия, не так очевидно.


Езернет это очень правильная сеть. И с пропускной способностью все в порядке. Страдает только латентность.

Но не стоит переходить на частности. В ЛЮБОЙ вычислительной сети может сложится "нехватка" пропускной способности и/или латентности. Я просто хотел показать ОДНОБОКОСТЬ утверждения о том, что скорость в параллельном вычислителе ограничена самым слабым узлом.

Код можно получать на любом процессоре, для любого другого. Все зависит от ключей компиляции. Все современные компиляторы позволяют на стареньком Pentium получать код оптимизированный для P4 и наоборот.