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

Про это

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

Естественно, эти тесты дают оценку производительности с плавающей запятой. Для каждого N известно, сколько операций с плавающей запятой нужно выполнить, чтобы решить систему линейных уравнений данным методом. Тогда, поделив число этих операций на время выполнения теста в секундах, можно получить оценку производительности в MFLOPS - миллионах операций с плавающей запятой в секунду. Отметим, что подобные оценки предполагают "равнозначность" различных операций с плавающей запятой, в том числе сложения и умножения, что является слабым местом: умножение может требовать больше тактов, чем сложение.

В тестах Linpack принято проводить расчеты при N=100 и N=1000, чему соответствует работа с векторами средней и большой длины соответственно. В таблицах обычно приводится также и третья характеристика - пиковая производительность R (теоретический предел числа операций с плавающей запятой в секунду). Для типичного суперскалярного микропроцессора (МП), умеющего выполнять за один такт одно сложение и одно умножение с плавающей запятой (при этом предполагается, что конвейеры заполнены), R=2xm, где m - тактовая частота в МГц.

Тесты Linpack для N=100 представляют собой программу на Фортране, исходный текст которой менять не разрешается. Лишь подпрограмма, возвращающая время выполнения, может считаться "своей" для данного компьютера. Таким образом, измеряемая производительность компьютера зависит от качества компилятора. Не исключено, что при "ручном" кодировании на языке Ассемблера теоретически и возможно было бы что-то улучшить, но программисты, как правило, все равно используют компилятор и "видят" именно такую производительность. Кроме того, современные компиляторы обычно умеют генерировать обращения к высокоэффективным (написанным на Ассемблере) подпрограммам линейной алгебры из пакета BLAS или встраивать соответствующие коды прямо в тело программы.

Эту своего рода "однозначность" (независимость от мастерства программиста) можно упомянуть в качестве одной из причин, почему в поддерживаемом нашей газетой списке top10 крупнейших российских суперкомпьютерных центров мы используем именно тест Linpack при N=100.

N=1000 допускает уже определенные "вольности" с текстом теста. Еще большие изменения становятся возможны при работе с тестом Linpack parallel, который IBM в своих информационных материалах обычно именует Linpack TPP. Задача этого теста - достижение максимальной производительности при неограниченном увеличении величины N. Поскольку это приводит к сверхбольшим векторам, для оценки того, сколь быстро с ростом N удается восходить к максимуму производительности, вводится понятие "половинной N", N(1/2) - размерности, при которой достигается половина от максимальной полученной производительности.

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

При N=100 распараллелиться практически не удается. Лишь для некоторых векторных супер-ЭВМ, в том числе компании SGI/Cray Research, имеются соответствующие данные, свидетельствующие о незначительном ускорении. Напротив, тест Linapck parallel всегда предполагает распараллеливание; результаты таких тестов имеются, в основном, для суперкомпьютерных систем. К недостаткам теста Linpack parallel cпециалисты в области суперкомпьютерных технологий часто относят тот факт, что позволяет так реализовать вычисления, что данные достаточно хорошо локализуются в кэше современных процессоров. Это означает, что уменьшается нагрузка на тракт "процессор-оперативная память", и его пропускная способность в нужной степени не тестируется.

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

Сквозь "линпаковский" кристалл

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

В табл. 1 представлены данные тестов Linpack parallel. В сравниваемых системах используются следующие микропроцессоры: DEC Alpha 21164 с частотой 600 МГц - в SGI/Cray T3E-1200; Sun UltraSPARC II с тактовой частотой 333 МГц - в серверах HPC 10000; IBM Power 2 (P2SC) c тактовой частотой 160 МГц - в серверах IBM SP2; РА-8000 с частотой 180 МГц и PA-8200 c частотой 240 МГц - в серверах от HP X- и V-класса соответственно; Alpha 21164 с тактовой частотой 440 МГц - в кластерах на базе SMP-серверов AlphaServer 8400; SGI/MIPS R10000 с тактовой частотой 195 МГц - в серверах Origin 2000. К сожалению, пока отсутствуют данные для 250 МГц версии R10000, а также результаты Linpack parallel для кластеров AlphaServer 8400 с 612-мегагерцевым Alpha 21164.

Таблица 1.
Производительность на тестах Linpack parallel, GFLOPS

Компьютер Производительность N(max) N(1/2) K
64-процессорные системы
Cray T3E-1200 43,9 61376 5600 57%
IBM SP2 29,5 27500 5700 72%
DEC AlphaServer 8400* 24,7 30712 4584 44%
HP X-сlass 27,6 29956 4584 60%
Sun HPC 10000 34,2 20352 3648 80%
SGI Origin 2000 20,1 40000 4000 80%
32-процессорные системы
Cray T3E-1200 22,0 43520 3552 58%
IBM SP2 14,9 20000 3840 75%
DEC AlphaServer 8400* 13,7 19176 4584 49%
HP X-class 15,0 26848 1840 65%
Sun HPC 10000 18,0 20352 1344 84%
SGI Origin 2000 10,9 32000 6400 87%
* Для Alpha 21164/440 МГц

Данные этой таблицы говорят не только об абсолютном уровне производительности (где очевидным лидером является Cray T3E), но и, в частности, о степени приближения к теоретической пиковой производительности (К, правый столбец таблицы). В этом отношении Cray T3E оказывается малоэффективным, а для достижения максимального уровня производительности ему требуются огромные значения N. Низкие значения К имеют и другие системы на базе Alpha 21164 - кластеры на основе DEC AlphaServer. Можно предположить, что это объясняется не столько собственно проблемами распараллеливания, сколько сложностями заполнения довольно длинных конвейеров данного микропроцессора.

Наибольшее значение К имеют SGI Origin 2000, а также Sun UltraEnterprise HPC 10000. Хотя 32-процессорные системы Sun по величине К чуть отстают от Origin 2000, последним требуются гораздо большие N для достижения максимума. А по параметру N(1/2) Sun оказывается впереди всех конкурентов.

Прежде чем рассмотреть тесты Linpack с N=100 и 1000, полезно упомянуть о результатах Linpack parallel для 16-процессорного HP V2250 на базе РА-8200/240 МГц (10,6 GFLOPS) и 12-процессорного DEC AlphaServer 8400/625 на базе 612-МГц Alpha 21164 (7,3 GFLOPS), поскольку в них применяются наиболее быстродействующие на сегодня МП.

В табл. 2. приведены данные для N=100, характеризующие производительность однопроцессорной системы. Здесь лидером является IBM, 160-мегагерцевый процессор P2SC которой не только лидируют по производительности, но и имеют наивысшее отношение К тестовых результатов к пиковой производительности. Эти микропроцессоры, как известно, отличаются большой пропускной способностью при обмене данными с оперативной памятью, но не имеют внешнего кэша. Первая особенность способствует увеличению производительности, вторая же не слишком опасна для тестов Linpack при N=100.

Таблица 2.
Производительность МП на тестах Linpack при N=100, MFLOPS

Компьютер Пр. K
IBM SP2 (Thin Node) 315 49%
AlphaServer 8400 5/625 287 23%
HP V2250 203 21%
Sun HPC 6000 154 23%

SGI не представила результаты тестов Linpack при N=100 для микропроцессора R10000/195 МГц. Можно, однако, предсказать, что К для этого процессора будет больше, чем для других, за исключением P2SC. Это связано со сложной микроархитектурой R10000 и относительно короткими конвейерами с плавающей запятой.

Посмотрим, наконец, как распараллеливается тест Linpack (N=1000) в анализируемых нами серверах. Часть соответствующих данных представлена в табл. 3. Данные для МРР-cистем Cray T3E и IBM SP2 для более чем одного микропроцессора отсутствуют.

Таблица 3.
Данные тестов Linpack (N=1000), MFLOPS (n - число процессоров)

Компьютер n Пр. Ускорение K
DEC AlphaServer 8400 5/625 (Alpha 21164/612 МГц) 8 3608 4,7 37%
4 2377 3,1 49%
2 1375 1,8 56%
1 764 1 62%
HP V2250 (PA-8200/240 МГц) 16 5367 7,3 35%
8 3706 5,1 48%
4 2272 3,1 59%
2 1264 1,7 66%
1 731 1 76%
Sun Ultra Enterprise6000 (UltraSPARC II/336 МГц) 16 3981 8,6 37%
8 2481 5,4 46%
4 1438 3,1 53%
2 843 1,8 63%
1 461 1 69%
SGI Origin 2000 (R10000/195 МГц) 16 3146 9,1 50%
8 2182 6,3 70%
4 1292 3,8 83%
2 667 1,9 86%
1 344 1 88%
IBM SP2 (P2SC/160 МГц) 1 532 1 83%

Из табл. 3 видно, что самым быстрым оказывается уже Alpha 21164, а не IBM P2SC, имеющий гораздо более низкую пиковую производительность. На втором месте - HP PA-8200. С точки зрения эффективности (К) лидером является SGI Origin 2000 (в том числе по причинам, указанным выше). Самое низкое значение К для процессора Alpha 21164 в первую очередь обусловлено, вероятно, уже упоминавшимися проблемами заполнения конвейеров.

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

В заключение хотелось бы предостеречь читателя - на основании представленных здесь данных не следует делать далеко идущих выводов. Целый ряд важных особенностей рассмотренных компьютеров мы не обсуждали; имеется немало других тестов, и в первую очередь реальные приложения; в расчет следует брать отношение стоимость/производительность и т. д. Одним словом, думайте сами, решайте сами!