Затраты на связь в суперкомпьютерах

10

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

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

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

hpc mpi

— Томас Кримерс
источник

2

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

— Дэвид Кетчесон

10

Давным любимым эталоном в высокопроизводительных вычислениях был эталонный тест HPLinpack, который измеряет скорость компьютерной системы в операциях с плавающей запятой в секунду при решении очень большой, плотной, линейной системы уравнений. Предполагается, что решение требует операций с плавающей запятой, и тестеру разрешено изменять для достижения максимальной производительности. $2/3n^{3}+2n^{2}$ $n$

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

Типичным для RPEAK является существенная доля RMAX, что указывает на то, что при выполнении этой эталонной задачи современные суперкомпьютеры могут достичь значительной доли своей теоретической пиковой производительности. Например, в рейтинге суперкомпьютеров TOP500 за ноябрь 2015 года самая быстрая машина, Tianhe-2, имеет RPEAK = 54,902 петафлопс и RMAX = 33,863 петафлопс.

Тем не менее, тест HPLinpack широко рассматривается как не представляющий текущие рабочие нагрузки. Результаты HPlinpack, как правило, значительно превышают производительность суперкомпьютеров в реальных приложениях.

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

Некоторые ранние результаты от HPCG составляют менее 5% от RPEAK. Например, Tianhe-2 имеет RPEAK = 54,902 петафлопс и HPCG при 0,58 петафлопс (см. Ссылку ниже на презентацию по HPCG).

Тесты TOP500 HPLinpack можно найти по адресу:

http://www.top500.org/

Презентацию по HPCG можно найти по адресу:

http://www.hpcg-benchmark.org/downloads/isc15/HPCG-ISC15-FINAL-SLIDES_update1.pdf

Веб-сайт HPCG находится по адресу

http://www.hpcg-benchmark.org/

— Брайан Борхерс
источник

1

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

2 / 3 n^{3} + 2 n^{2}

$2/3n^3 + 2n^2$

— Аврелий

3

Это, кажется, не отвечает на вопрос, так как ничего не говорит о передаче сообщений.

— Дэвид Кетчон

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

— Брайан Борчерс

6

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

На самом деле, вопрос не совсем ясен. Если на коммуникационной карте узла кластера есть процессор, который можно использовать только для связи, как вы подсчитываете время, которое эта карта простаивает, не обрабатывая связь (или что-либо еще)? То есть что считается «доступной вычислительной мощностью»? Считаем ли мы плохо написанные программы, которые имеют неоптимизированные вычислительные и коммуникационные процедуры, такими же, как оптимизированные? Что если кто-то использует известный анти-паттерн в своем коде, который намеренно недостаточно использует процессор? Как насчет смущающе параллельных программ, которые вообще не взаимодействуют (я обещаю, что они запускаются на суперкомпьютерах)?

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

— Билл Барт
источник