Отчет по тестированию кластера IBM1350, оснащенного HW и

Отчет
по тестированию кластера ibm1350,
оснащенного HW и SW фирмы Intel
Исполнители
Маркова В.П.
Киреев С.Е.
Городничев М.А.
Перепелкин В.А.
Калгин К. А.
Щукин Г. В.
Содержание отчета
1. Введение. Цели тестирования кластера ibm1350.
2. Особенности программного обеспечения.
a. Нумерация ядер в узле кластера ibm1350.
b. Привязка в сочетании MPI+OpenMP.
c. Использование больших массивов.
3. Пакет тестирования систем с общей памятью.
4. Синтетические тесты.
a. Влияние привязки процессов и потоков к ядрам узла на скорость
обмена данными.
b. Влияние шины на пропускную способность памяти при
различных способах обхода массива.
c. Исследование конкурентного доступа к памяти.
5. Тестирование узла кластера ibm1350 на программе решения СЛАУ с
разреженными матрицами методом бисопряженных градиентов.
6. Тестирование характеристик кластера ibm1350 с помощью тестового
пакета.
7. Выводы.
1. Введение. Цели тестирования кластера ibm1350
Целью тестирования кластера IBM System Cluster 1350 является
выявление особенностей программного и аппаратного обеспечения и их
влияние на время выполнения программ численного моделирования.
Некоторые характеристики серверов IBM BladeCenter приведены в
табл.1. Кластер состоит из 6 «блейд-серверов» IBM BladeCenter HS21xx, один
из которых управляющий, один запасной и четыре вычислительных.
Вычислительный модуль состоит из двух 4-х ядерных процессор Intel Xeon
Табл. 1.
Характеристика
Вычислительный модуль
Управляющий модуль
Сервер
BladeCenter HS21
BladeCenter HS21XM
Процессор
2xIntel Xeon 1.86GHz
2xIntel Xeon 2.33GHz
Ядер в узле
4 (2 х 8)
4 (2 х 8)
ОЗУ
4x2GB
8x2GB
Кэш-память
L1: 32 + 32 KB
L2: 4 × 4 MB*
Межсоединение
InfiniBand
Производительность
ядра (пиковая)
Производительность
кластера (пиковая)
7.44 GFlops
9.28 GFlops
238 GFlops
-
*Общий кэш 4 МБ на 2 ядра
5320 “Clovertown”. Кэш второго уровня динамически разделяется между
двумя ядрами. Два ядра, в зависимости от взаимного расположения могут
обмениваться информацией либо через кэш 2 уровня, либо через шину FSB.
Все 8 ядер для чтения /записи данных в ОЗУ, а так же для синхронизации
одних и тех же данных в разных кэшах используют общую шину (FSB).
На кластере установлена операционная система Red Hat Enterprise
Linux и параллельная файловая система IBM General Parallel File System.
Система управления пакетными заданиями – IBM Load Leveler.
Компиляторы Intel C++ и Intel Fortran версии 10.1, а так же Intel MKL версии
10.0 и Intel MPI 3.0. См. также приложение 1.
Процессор 0
Ядро
Ядро
Кэш L2
Ядро
Процессор 1
Ядро
Ядро
Кэш L2
Ядро
Ядро
Кэш L2
Ядро
Кэш L2
Шина FSB
ОЗУ
Рис.1. Иерархия памяти узла ibm1350
2. Особенности программного обеспечения
В процессе эксплуатации кластера ibm1350 выяснились следующие
факты:
1. MPI использует привязку процессоров к ядрам по умолчанию, что при
существующей нумерации ядер влечет неравномерную загрузку ресурсов
процессора.
2. Существуют ограничение на использование массивов большого размера
на имеющемся программном обеспечении.
Первая проблема решается с помощью явной привязки процессов к ядрам.
Вторая – использованием динамических массивов.
2.a. Привязка задач к ядрам в узлах ibm1350
В современных серверах с общей памятью все вычислительные ядра
имеют уникальные номера. Так как некоторые ядра могут иметь общие
ресурсы (исполнительные устройства, кэш-память), нужно знать
соответствие номеров ядер их физическому расположению. Это позволит
более эффективно планировать распределение задач.
Выяснилось, что ядра в процессорах расположены следующим образом
(см. рис. 2). Эффект от такой нумерации ядер поясним на следующем
примере. При запуске задач MPI на кластере ibm1350 ядра в узле получают
задания в порядке возрастания их номеров. Так, при запуске 4-х процессов
MPI на узел начинают работать ядра с номерами 0, 1, 2 и 3. При этом ядра 0 и
2 работают над одной кэш-памятью, ядра 1 и 3 монопольно владеют кэшпамятью, а ядра 6 и 7 вообще не используются кэш-памяти (рис. 3а).
Кэш L2
Кэш L2
Кэш L2
Кэш L2
Ядро Ядро Ядро Ядро
0
2
3
4
Ядро Ядро Ядро Ядро
1
5
6
7
Процессор 0
Процессор 1
Рис. 2. Нумерация ядер в узле кластера ibm1350.
Кэш L2
Кэш L2
Кэш L2
Кэш L2
0
3
1
6
2
4
Процессор 0
5
7
Процессор 1
а)
Кэш L2
0
2
Кэш L2
3
Кэш L2
4
1
Процессор 0
5
Кэш L2
6
7
Процессор 1
б)
Рис. 3. Распределение 4-х процессов MPI по ядрам: а) неоптимальное
распределение (по умолчанию), б) оптимальное распределение.
Такое распределение ядер не является оптимальным. В общем случае
более эффективно было бы расположить ядра 0, 1, 2, 3 над различными
блоками кэша L2, чтобы полностью задействовать имеющуюся кэш-память
(Рис. 3б).
2.b. Привязка потоков к ядрам в сочетании MPI+OpenMP
При запуске программ, распараллеленных с помощью сочетания MPI и
OpenMP, было обнаружено, что для работы используются не все доступные
ядра узла. В результате исследования выяснилось, что при запуске MPIпрограммы процессы получают привязку к ядрам, и все порождаемые ими
потоки наследуют эту привязку. Таким образом, если программа запустила 2
процесса MPI на 2-х ядрах, а потом каждый процесс породил еще три потока,
то работать будут все равно 2 ядра – по четыре потока на каждом ядре (рис.
4а).
Чтобы задействовать остальные ядра (рис. 4б), необходимо в
программе явно задавать привязку потоков к ядрам. В приложении 1
приведен пример задания привязки в программе на С++ с использованием
MPI+OpenMP.
MPI процесс 0
поток 0
поток 1
поток 2
поток 3
0
MPI процесс 0
поток 0
2
MPI процесс 0
поток 1
3
3
MPI процесс 0
поток 2
4
4
MPI процесс 0
поток 3
1
MPI процесс 1
поток 0
5
MPI процесс 1
поток 1
6
6
MPI процесс 1
поток 2
7
7
MPI процесс 1
поток 3
0
2
MPI процесс 1
поток 0
поток 1
поток 2
поток 3
1
5
(а)
(б)
Рис.4. Распределение процессов и потоков в сочетании MPI+OpenMP по
ядрам узла ibm1350: а) распределение по умолчанию, б) явно заданное
оптимальное распределение.
2.c. Компиляция программ с массивами большого размера
При использовании кластера ibm1350 выяснилось, что на имеющемся
программном обеспечении не компилируются или не запускаются некоторые
программы, использующие массивы большого размера. Кроме того, на успех
запуска влияло используемое средство параллельного программирования.
Следующие особенности использования больших массивов были проверены
на машине IBM 1350 для компиляторов фирмы Intel версии 10.1.
Выяснилось, что при использовании динамических массивов любого
размера проблем с компиляцией и запуском не возникает. При
использовании же статических массивов существуют следующие
ограничения:
 В программах на Си большие статические массивы должны быть
глобальными, т.е. быть объявлены за пределами любой функции,
независимо от того, использует ли программа OpenMP.
 Если программа на C++ не использует OpenMP, она может
использовать глобальные статические массивы любого размера. Если
программа использует OpenMP, то суммарный объем глобальных
данных не может превышать объема 2042MB (иначе возникает ошибка
компиляции).
 Суммарный объем статических данных в программах на Фортране не
может превышать объема 2042MB (иначе возникает ошибка
компиляции). Если программа на Фортране не использует OpenMP, то
большие статические массивы могут быть объявлены в главной
программе или в COMMON-блоках. Если же программа использует
OpenMP, то все большие статические массивы должны располагаться
только в COMMON-блоках.
Выводы. Проведенные тесты позволили сделать следующие выводы.
1. Для оптимального использования ресурсов узла необходимо явно
задавать привязку процессов и потоков к ядрам.
2. При использовании сочетания MPI+OpenMP следует явно задавать
привязку потоков к ядрам.
3. В программах, работающих с большими объемами данных,
рекомендуется использовать динамические массивы. Использование
больших статических массивов в некоторых случаях возможно только
с ограничениями на размер.
3. Пакет для тестирования многоядерных систем
Настоящий пакет разработан для оценки производительности
современных систем с общей памятью на задачах численного
моделирования. Пакет включает следующий набор задач:
 умножение матрицы на вектор,
 умножение матрицы на матрицу,
 решение СЛАУ методом простой итерации,
 решение СЛАУ методом сопряженных градиентов,
 решение двумерного уравнения Пуассона методом Якоби.
Задачи реализованы с помощью различных средств параллельного
программирования. На данный момент существуют следующие реализации:
 MPI
 OpenMP
 MPI+OpenMP
 POSIX Threads
 Intel TBB
Некоторые задачи имеют две реализации в MPI и MPI+OpenMP:
 Умножение матрицы на вектор, решение СЛАУ (в части умножения
матрицы на вектор):
1. Матрица и вектор распределены между процессами: MPI(1),
2. Матрица распределена, а вектор дублируется во всех процессах:
MPI(2).
 Умножение матрицы на матрицу:
1. Обе матрицы распределены между процессами: MPI(1),
2. Первая матрица распределена, а вторая дублируется во всех
процессах: MPI(2).
Время, с
Также все задачи имеют две реализации в TBB: с фиксированным
(TBB(1)) и автоматическим (TBB(2)) разбиением на параллельные блоки. В
реализациях TBB(2) использовалось средство TBB auto_partitioner().
В дополнение к задачам был создан набор управляющих скриптов для
автоматизации процесса компиляции, запуска задач пакета и сбора
результатов. Для использования пакета на конкретной вычислительной
машине требуется задание только нескольких параметров, таких как
используемые компиляторы и опции компиляции. Возможно указание того,
какие группы тестов должны быть запущены и сколько запусков теста
следует произвести.
На рис. 5 приведены результаты запуска тестового пакета на задаче
умножения матрицы на матрицу (размер матриц 640*640, тип данных double,
5 повторений, различные средства параллельного программирования).
10
9
8
7
6
5
4
3
2
1
0
1 процесс
2 процесса
4 процесса
8 процессов
MPI(1)
MPI(2)
OpenMP
pthreads
TBB(1)
Библиотека распараллеливания
TBB(2)
Рис.5. Результаты запуска тестового пакета.
Данный пакет позволяет проводить тестирование кластеров и их узлов
на различных задачах, написанных с использованием различных средств
распараллеливания.
4. Синтетические тесты
Известно, что время обмена данными при параллельной реализации
задачи может быть достаточно велико, поэтому важно исследовать влияние
различных факторов на временные характеристики памяти.
Проводилось тестирование подсистемы памяти в узле. Исследовалось
влияние на временные характеристики следующих факторов:
1. привязка потоков к ядрам,
2. способы обхода данных в памяти,
3. взаимное расположение данных различных потоков.
4.a. Влияние привязки процессов и потоков к ядрам на скорость обмена
данными
Зависимость времени выполнения программы от привязки процессов
или потоков к ядрам исследовалась на примере задачи круговой пересылки
данных. Задача состоит в том, что каждый процесс принимает и передает
данные одинакового размера по кругу. Параллельный алгоритм был
реализован с помощью библиотеки MPI. Программа создает 8 процессов MPI
(по числу ядер в узле). Привязка к ядрам выполняется по одному из двух
вариантов.
 «Оптимальная»: Привязка процессов совпадает с физическим
расположением ядер (рис.6а).
 «Плохая»: Соседние процессы в круге привязываются к максимально
удаленным ядрам, каждая передача проходит через шину (рис.6б).
1
2
3
4
1
5
3
7
8
7
6
5
2
6
4
8
а)
б)
Рис.6. Два варианта привязки процессов к ядрам: а) «оптимальная» привязка,
б) «плохая» привязка.
Тестирование произведено для различных размеров задачи. Результаты
показали, что влияние привязки процессов в задачах с круговой пересылкой
данных незначительное (в пределах 1-2%) вне зависимости от размеров
пересылаемых данных. Такие же результаты показал аналогичный тест с
использованием POSIX Threads.
4.b. Влияние способа обхода данных и количества потоков на
пропускную способность памяти узла кластера ibm 1350
Пропускная способность памяти узла кластера ibm1350 исследовалась
в зависимости от следующего:
1. количества работающих потоков (процессов),
2. способа обхода данных (последовательный, случайный),
3. объема данных.
Относительная пропускная способность
В тесте привязка потоков к конкретным ядрам не учитывается, обход
данных выполняется последовательно и случайно, данные между потоками
не разделяются.
На рис.7 показана зависимость относительной пропускной способности
одного потока от количества одновременно работающих потоков и объема
данных при случайном обходе памяти. Пропускная способность дана
относительно результата на одном процессоре. Абсолютные величины
пропускной способности (MB/s) указаны в табл.2. Из результатов видно, что
при объемах данных порядка 1 МB, пропускная способность практически не
меняется, т.к. данные находятся в кэш-памяти. При увеличении объема
данных начинают происходить обращения к общей памяти, и пропускная
способность каждого отдельного потока снижается.
1,2
1
0,8
1 поток
2 потока
0,6
4 потока
8 потоков
0,4
0,2
0
64 MB
32 MB
1 MB
Объем данных
Рис.7. Зависимость пропускной способности для одного потока от
количества потоков и объема обрабатываемых данных (случайный обход)
Табл.2.
1
2
4
8
64 MB
36,8
32
28,5
21
32 MB
39,5
33,8
30,5
22,2
16 MB
45,5
39,1
35,5
23,8
8 MB
65
59
51,5
28
4 MB
215
195
190
42
2 MB
547
546
541
185
1 MB
670
670
670
670
Относительная пропускная способность
На рис.8 показана зависимость относительной пропускной способности
для одного потока от количества потоков и объема данных при
последовательном обходе памяти. Абсолютные величины пропускной
способности указаны в таблице 3. Характер зависимости похож на
результаты для случайного обхода. Но при последовательном обходе темп
передачи данных намного выше благодаря аппаратной предвыборке. В
результате при увеличении числа потоков пропускная способность
системной шины быстро исчерпывается, и темп передачи данных для
каждого отдельного потока резко падает.
1,2
1
0,8
1 поток
2 потока
0,6
4 потока
8 потоков
0,4
0,2
0
64 MB
32 MB
1 MB
Объем данных
Рис.8. Зависимость пропускной способности для одного потока от
количества потоков и объема обрабатываемых данных (последовательный
обход)
1
2
4
8
64 MB
2200
2170
1475
761
32 MB
2260
2150
1470
760
16 MB
2230
1950
1480
760
8 MB
2280
2200
1650
765
4 MB
2460
2440
2400
870
2 MB
2560
2570
2570
2210
Табл.3.
1 MB
2560
2580
2580
2580
4.c. Накладные расходы на синхронизацию данных при доступе в память
двух потоков
Накладные расходы на синхронизацию данных определялись с
помощью записи данных двумя потоками в ячейки памяти, отстоящие друг
от друга на различном расстоянии. Потоки к ядрам привязывались
различными способами.
Тест проводился на узле московского кластера MBC-100k на базе 4ядерных процессоров Xeon 5365 (Clowertown) 3 GHz. От процессоров Xeon
5320 (Clowertown) 1.86 GHz на проходившем тестирование кластере ibm1350
эти процессоры отличаются только частотой, поэтому общий характер
результатов на этих машинах должен совпадать, отличаясь только по
абсолютной величине.
Результат показан на рис.9 (разными цветами обозначены различные
способы привязки потоков к ядрам). Из рисунка видно, что накладные
расходы отсутствуют, если данные потоков размещены в разных строках
кэш-памяти – на расстоянии более 64 байт.
0,003
Время, с
0,0025
0,002
0,0015
0,001
0,0005
0
0
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384
Расстояние между ячейками, байт
Рис.9. Зависимость времени выполнения от взаимного расположения данных
в памяти.
Выводы. Результаты тестирования показали следующее:
1. Привязка потоков к ядрам не влияет на время передачи данных между
ними.
2. При одновременной работе нескольких потоков пропускная
способность памяти каждого потока значительно снижается (по
сравнению с одним потоком). При этом сильнее возрастает время
последовательного обхода по сравнению со случайным обходом. То
есть, программы с последовательным доступом в память сильнее
подвержены «бутылочному горлу» общей шины.
3. Накладные расходы на синхронизацию данных в кэш-памяти
отсутствуют, если данные различных потоков размещаются на разных
строках кэш-памяти.
4. Время доступа к своей и удаленной кэш-памяти совпадает.
5. Тестирование узла кластера ibm1350 на программе решения СЛАУ с
разреженными матрицами методом бисопряженных градиентов.
Производительность узла кластера ibm1350 определялась на примере
задачи решения СЛАУ методом бисопряженных градиентов для
разреженных матриц. В качестве данных использовались матрицы, взятые из
реальных задач моделирования (табл.4). Эти матрицы, взяты из коллекции
матриц
университета
Флориды:
http://www.cise.ufk.edu/research/sparse/matrices.
Табл.4.
Название
Описание
матрицы происхождения
Размер
Bayer02
Unsymmetric
20545
Rajat26
Circuit
simulation
matrix
51032
Graham1
Galerkin FE
disc. Of Nav.
Stokes 2phase
fluid flow
Femlab, 3D
Navier-Stokes
9035
Ns3da
Cage13
DNA
electrophoresis.
13 monomers in
polymer
20414
445315
Кол-во
Ссылка на страницу
ненулевых
матрицы в коллекции
элементов
159082
http://www.cise.ufl.edu/
research/
sparse/matrices/Grund/b
ayer04.html
249302
http://www.cise.ufl.edu/
research/
sparse/matrices/Rajat/ra
jat26.html
335504
http://www.cise.ufl.edu/
research/
sparse/matrices/Graham
/graham1.html
1679599
http://www.cise.ufl.edu/
research/
sparse/matrices/FEMLA
B/ns3Da.html
7479343
http://www.cise.ufl.edu/
research/
sparse/matrices/vanHeu
kelum/cage13.html
Тип элементов данных в программе: double (8 байт). В тесте
измерялось время выполнения 100 итераций метода. Программа реализована
в последовательном и параллельном вариантах.
На рис.10 приведены величины времени выполнения последовательной
программы в узле кластера ibm1350 в сравнении с другими процессорами.
Матрицы упорядочены по возрастанию числа ненулевых элементов.
18
Pentium M 1.7GHz
16
Celeron 1.7GHz
Время, с
14
PowerPC 970FX 2.2 GHz
Itanium2 (Smp4x64) 1.5 GHz
12
Xeon 5150 (Woodcrest) 2.66 GHz
10
Xeon 5320 (Clowertown) 1.86 GHz
8
6
4
2
0
Bayer
Rajat
Graham
Ns3Da
Cage
Матрицы входных данных
Рис. 10. Время выполнения программы для различных процессоров на
различных входных данных
На данных малого размера (порядка размера кэш-памяти) наибольшее
значение имеет производительность используемого процессора. Woodcrest
показывает лучшие результаты, т.к. имеет более высокую частоту. С ростом
объема данных решающим оказывается производительность подсистемы
памяти, и здесь на первое место выходит Clowertown. Процессор Itanium2 (с
частотой ниже, чем у всех остальных процессоров) занимает промежуточное
положение между Woodcrest и Clovertown, а на одной из матриц среднего
размера даже обгоняет остальных.
На рис.11 приведены величины времени выполнения параллельной
программы в узле кластера ibm1350. Параллельная программа была получена
из последовательной, использовавшейся в предыдущем тесте, посредством
распараллеливания циклов с помощью директив OpenMP.
6
1
2
5
3
4
Время, с
4
5
3
6
7
2
8
9
1
10
16
0
Cage
Ns3Da
Rajat
Graham
Матрицы входных данных
Рис. 11. Зависимость времени выполнения программы для разных данных
от числа потоков
Незначительное ускорение наблюдается только до 4-х параллельных
потоков.
Выводы. Результаты тестов позволяют сделать следующие выводы:
1. На последовательной программе с большим объемом данных
Clovertown имеет лучший результат благодаря быстрой подсистеме
памяти.
2. На параллельной программе ускорение имеет место только до 4
потоков, вероятно, вследствие ограниченной пропускной способности
памяти.
6. Тестирование кластера ibm1350 с помощью тестового пакета
Кластер ibm1350 тестировался с помощью следующих задач пакета,
описанного в пункте 3:
1. Умножение матрицы на матрицу.
2. Решение СЛАУ методом сопряженных градиентов.
3. Решение СЛАУ методом простой итерации.
Определена
зависимость
времени
выполнения
программ
перечисленных задач от способов привязки процессов и потоков к ядрам и
средства параллельного программирования (MPI (2 варианта), OpenMP,
MPI+OpenMP (2 варианта), Posix Threads, TBB (2 варианта)). Для
тестирования использовался компилятор Intel C/C++ Compiler 10.1 с ключом
оптимизации –O3.
На рис.12 показана зависимость времени выполнения программ на
одном узле от количества процессов/потоков (привязка по умолчанию) для
указанных средств параллельного программирования. Размер задачи:
2000×2000, тип данных: double. Результаты тестов показывают, что
программы, реализованные с использованием MPI, преимущественно
уступают по времени остальным программам.
MPI(1)
Метод сопряженных градиентов
MPI(2)
100
90
80
70
60
50
40
30
20
10
0
OpenMP
OpenMP
20
PThreads
TBB(1)
TBB(2)
MPI(1)
MPI(2)
25
Время, с
Время, с
Умножение матрицы на матрицу
PThreads
TBB(1)
15
TBB(2)
10
5
0
1
2
4
8
Число процессов/потоков
Метод простой итерации
30
2
4
8
Число процессов/потоков
MPI(1)
MPI(2)
OpenMP
25
Время, с
1
PThreads
20
TBB(1)
15
TBB(2)
10
5
0
1
2
4
8
Число процессов/потоков
Рис. 12. Время выполнения задач при использовании различных средств
параллельного программирования
На рис.13 показана зависимость времени выполнения программ на
MPI+OpenMP на одном узле от различных соотношений процессов MPI
(первое число) и потоков OpenMP (второе число) и их привязки к ядрам.
Для запусков с 4-мя процессами по 2 потока и 2-мя процессами по 4
потока распределение потоков по ядрам осуществлялось двумя способами:
 «потоки в разных кэшах» – потоки одного процесса делят кэш-память с
потоками других процессов,
 «потоки в одном кэше» – потоки одного процесса не делят кэш память
с потоками других процессов.
Умножение матрицы на матрицу
Метод сопряженных градиентов
8
Вариант 1
Вариант 2
16
7
14
6
12
5
Время, с
Время, с
18
10
8
3
2
4
1
2
0
0
потоки потоки потоки потоки
в
в одном
в
в одном
разных кэше разных кэше
кэшах
кэшах
потоки в потоки в потоки в потоки в
разных одном разных одном
кэшах
кэше кэшах
кэше
4_2
2_4
Вариант 2
4
6
8_1
Вариант 1
1_8
8_1
Метод простой итерации
4_2
2_4
1_8
Вариант 1
8
Вариант 2
7
Время, с
6
5
4
3
2
1
0
потоки в потоки в потоки в потоки в
разных одном разных одном
кэшах
кэше кэшах
кэше
8_1
4_2
2_4
1_8
Рис. 13. Время выполнения задач при использовании различных способов
привязки
Из рисунка видно, что если потоки одного процесса работают над
общей кэш-памятью, то время выполнения программы перемножения матриц
уменьшается примерно на 25%, для остальных задач изменения
незначительные.
На рис.14 показана зависимость времени выполнения программ на
MPI+OpenMP на всех 4х узлах кластера от различных соотношений
процессов MPI (первое число) и потоков OpenMP (второе число) и их
привязки к ядрам. Размер задачи: 5000×5000, тип данных: double.
Для запусков с 4-мя процессами по 2 потока и 2-мя процессами по 4
потока распределение потоков по ядрам осуществлялось двумя способами:
 «неупорядоченное» – потоки распределялись по ядрам в произвольном
порядке,
 «упорядоченное» – потоки распределялись по ядрам так, чтобы потоки
разных процессов не занимали общую кэш-память.
Метод простой итерации
Вариант 1
Вариант 1
12,5
Вариант 2
Вариант 2
Время, с
12
11,5
11
10,5
10
8_1
4_2
2_4
Неупорядоченное
распределение
потоков
Упорядоченное
распределение
потоков
Неупорядоченное
распределение
потоков
Упорядоченное
распределение
потоков
Упорядоченное
распределение
потоков
Неупорядоченное
распределение
потоков
Упорядоченное
распределение
потоков
9,5
Неупорядоченное
распределение
потоков
Время, с
Умножение матрицы на матрицу
90
80
70
60
50
40
30
20
10
0
1_8
8_1
Метод сопряженных градиентов
13
4_2
2_4
1_8
Вариант 1
Вариант 2
Время, с
12,5
12
11,5
11
10,5
10
Неупорядоченное
распределение
потоков
Упорядоченное
распределение
потоков
Неупорядоченное
распределение
потоков
Упорядоченное
распределение
потоков
9,5
8_1
4_2
2_4
1_8
Рис. 14. Время выполнения задач при использовании различных способов
привязки
Из рисунка видно, что для задач решения СЛАУ (использующих
только векторные и векторно-матричные операции) замена процессов
потоками ведет к ускорению. Для задачи перемножения матриц ускорение
имеет место только при определенном соотношении процессов и потоков и
при оптимальной привязке потоков к ядрам.
Выводы. Тестирование показало следующее:
1. Использование сочетания MPI и OpenMP на кластерах с
многоядерными узлами может уменьшить время счета по сравнению с
MPI.
2. Явная привязка потоков к ядрам с учетом архитектурных особенностей
процессора позволяет в некоторых случаях еще повысить
производительность.
7. Выводы.
Исходя из проведенного тестирования, наиболее эффективным способом
использования ресурсов кластера ibm1350 будет использование сочетания
процессов MPI и какого-либо средства программирования в потоках,
например OpenMP. При этом потоки должны быть явно привязаны к ядрам,
так, чтобы потоки различных процессов работали над различными кэшами.
Кроме
того,
справедливы
следующие
факты,
касающиеся
производительности:
1. Для программ, интенсивно работающих с памятью, ограниченная
пропускная способность общей памяти может ограничить
производительность кластера в целом.
2. Расположение данных различных потоков на расстоянии более 64 байт
избавит от накладных расходов на синхронизацию.
3. Взаимное расположение ядер в узле никак не влияет на время передачи
данных между ними.
Подсистема памяти узла кластера ibm1350 хотя и имеет свое ограничение на
пропускную способность, все же показывает лучшие результаты
производительности по сравнению с другими вычислительными системами
(Itanium2, Woodcrest).
Приложение 1
Пример задания привязки в программе на С++ с использованием
MPI+OpenMP для случая выполнения двух процессов MPI по четыре потока
OpenMP на узле, имеющем в сумме 8 ядер.
#include<mpi.h>
#include<omp.h>
#include<stdio.h>
#include<sched.h>
int main(int argc,char *argv[])
{ int mpi_rank,omp_rank,core;
MPI_Init(&argc,&argv);
MPI_Comm_rank(MPI_COMM_WORLD,&mpi_rank);
omp_set_num_threads(4); // по 4 потока на MPI-процесс
#pragma omp parallel shared(mpi_rank) \
private(omp_rank,core)
{ cpu_set_t mask1,mask2;
omp_rank=omp_get_thread_num();
// по 2 процесса на узел, по 4 потока на процесс
core=(mpi_rank % 2)*4 + omp_rank;
CPU_ZERO(&mask1); // обнуление маски
CPU_SET(core,&mask1); // задание бита в маске
sched_setaffinity(0,sizeof(cpu_set_t),&mask1);
sched_getaffinity(0,sizeof(cpu_set_t),&mask2);
printf("Process %d Thread %d Affinity: %d\n",
mpi_rank,omp_rank,*((int*)&mask2));
}
MPI_Finalize();
return 0;
}
Приложение 2. Программное обеспечение, установленное на кластере
ibm1350.
Операционная система: Red Hat Enterprise Linux AS release 4 (Nahant Update
5)
Система управления кластером IBM Cluster Systems Management (CSM) для
Linux
Стек протоколов InfiniBand Cisco_OFED-1.2.5
Система управления пакетными заданиями IBM LoadLeveler
Файловая система IBM General Parallel File System (GPFS)
Компиляторы Intel C++ и Intel Fortran версии 10.1
Intel MKL версии 10.0
Intel MPI версии 3.0