В наших предыдущих исследованиях, мы уже неоднократно рассматривали различные многопроцессорные и/или многоядерные конфигурации платформ AMD Opteron (с результатами этих исследований можно познакомиться в статьях «SPEC CPU2000. Часть 12.1. Изучение архитектуры AMD Opteron. Интегрированный контроллер памяти и двухпроцессорные конфигурации» и «SPEC CPU2000. Часть 21. Платформа AMD Opteron: двухпроцессорные и «двухпроцессорно-двухъядерные» системы»). В настоящей статье мы вновь возвращаемся к этим платформам, на сей раз представленным сервером STSS QDD4400, построенным на базе четырех двухъядерных процессоров AMD Opteron 875. Важнейшая особенность этой платформы заключается в реализации более сложной, 4-узловой конфигурации неоднородной архитектуры памяти (NUMA), теоретическому изучению которой была посвящена отдельная статья. Что ж, теория — теорией, оценим теперь эффективность «8-ядерной» платформы AMD Opteron в реальных вычислительных задачах, примерами которых являются задачи тестового пакета SPEC CPU2000.
Конфигурация тестового стенда и ПО
- Платформа: STSS QDD4400
- Процессоры: 4x AMD Dual Core Opteron 875, 2.2 ГГц, ревизия ядра E1
- Материнская плата: NEWISYS 3U4P, версия BIOS V2.34.5.1, 11/08/2005
- Чипсет: AMD 8111 & 8131 PCI-X Tunnel
- Память: 16x Corsair 1ГB DDR-333 ECC Registered
- Видео: Trident Blade3D
- HDD: Seagate ST336807LC, Ultra320 SCSI, 10000 rpm, 36Gb
- ОС: Windows Server 2003 SP1
В нашем исследовании мы воспользуемся новой официальной версией 1.3 тестов SPEC CPU 2000, откомпилированных в Intel C++/Fortran Compiler 9.0 (версии обоих пакетов — 9.0.024). Учитывая, что тестируемая платформа основана на процессорах AMD, мы воспользовались, как обычно, нашей вспомогательной программой ICC Patcher с целью устранения проверок на соответствие производителя процессора компании Intel во всех библиотеках Intel-овских компиляторов C++/Fortran.
В тестах SPEC использовалась метрика «производительность» (rate). Напомним, что она измеряет «количество выполненных заданий за единицу времени» и таким образом лучше подходит для оценки скорости многопроцессорных систем, чем классическая «скорость исполнения одной задачи».
Ввиду ограниченности доступного времени для тестирования рассматриваемой платформы, мы провели лишь минимально возможный набор тестов, а именно, запуск 1, 2, 4 и 8 копий тестовых задач (параметры запуска: --rate 1, --rate 2, --rate 4 и --rate 8, соответственно). Во всех случаях, в настройках подсистемы памяти NUMA использовался режим SRAT, включенный на данной платформе по умолчанию. Напомним, что суть SRAT (System Resource Affinity Table) заключается в создании особой таблицы с одноименным названием в пространстве имен ACPI, которая позволяет операционной системе правильно ассоциировать процессоры и принадлежащие им области памяти — что, в случае NUMA-систем, оказывается весьма полезным. Это выполняется при условии поддержки данной технологии со стороны ОС, к числу которых относится установленная на данной платформе ОС Windows Server 2003 SP1.
Заметим, что поддержка SRAT в Windows Server 2003 SP1 проявляет себя вполне явным образом — в показаниях загрузки процессоров в диспетчере задач. Как известно, обычные системы класса Windows NT распределяют процессорное время так, чтобы все процессоры были загружены равномерно. Например, при наличии в системе 8 процессоров (не важно, каких: физических или логических) и запуске 4 активных приложений каждый из процессоров будет загружен на 50%. В случае же ОС Windows Server 2003, поддерживающей SRAT, как было выяснено экспериментально, нагрузка распределяется неравномерно. Например, в один момент времени полностью (на 100%) загруженными оказываются 1-й, 2-й, 5-й и 7-й процессоры, а примерно через 5-секундный интервал — соответственно, 3-й, 4-й, 6-й и 8-й процессоры, после чего порядок нагрузки процессоров может изменяться на другой. В результате (при достаточно большом усреднении по времени) по-прежнему достигается сбалансированная загрузка всех процессоров, но достигается она иным путем. Поскольку теперь каждый поток/приложение не «размазывается» по всем процессорам, а работает сравнительно продолжительное время только на одном из них, в NUMA-системах повышаются шансы обращения этого потока/приложения к «своей» памяти, размещенной в адресном пространстве контроллера данного процессора. Конечно, с равным успехом можно говорить и о возможности реализации проигрышного варианта, когда приложение оказывается привязанным к одному процессору, но работает с данными, расположенными в адресном пространстве контроллера другого процессора (вплоть до «дважды удаленного» от процессора, исполняющего код). Но, будем надеяться, что ОС, поддерживающие SRAT, все же должны «понимать», как именно раскидывать приложения по процессорам с точки зрения обращения к памяти.
Результаты тестов
Итак, переходим к рассмотрению результатов наших тестов «8-ядерной» платформы AMD Opteron 875 в SPEC CPU2000. В качестве эталона, вполне логично рассматривать случай «одиночного» запуска каждой из задач (параметр запуска --rate 1). Заметим, что новая версия 1.3 тестового пакета SPEC CPU2000 преподнесла нам интересный сюрприз (по крайней мере, с используемыми версиями компиляторов Intel) в виде целочисленной задачи 255.vortex, которая отказалась выполняться корректно (результат не совпадал с эталонным) во всех вариантах оптимизации кода. В связи с этим, эта задача не будет фигурировать в нижеприведенных графиках.
2 задачи
Рассматриваем первый случай: параллельный запуск двух задач (которые, в связи со сказанным выше, в каждый определенный момент времени могут исполняться как на двух независимых физических процессорах, так и на двух ядрах одного и того же процессора, причем эта картина меняется во времени так, чтобы «охватить» в целом все доступные в системе исполнительные устройства), целочисленные тесты SPECint2000.
Большинство задач ведут себя вполне адекватно, показывая ровно двукратный прирост (или очень близкий к нему) относительно запуска одной копии задачи. Исключение составляют 181.mcf (демонстрирующая наибольший разброс, в зависимости от варианта оптимизации кода — от 1.50 до 2.06 раз), 254.gap и 300.twolf (здесь наблюдается меньший разброс, от ~1,9 до 2,10 раз), некоторый выброс дает также 175.vpr (вариант -QxW, прирост в 1,87 раз). Прирост в целом, по оценке SPECint_base2000, составляет от 1,93 до 2,01 раз. По не совсем понятным причинам, тесты SPEC не выдали интегральную оценку для варианта оптимизации кода -QxP (использующего SSE3-инструкции, хотя, для целочисленного кода это несущественно), несмотря на то, что все задачи целочисленного подмножества тестов благополучно запустились и корректно завершили свою работу (за исключением 255.vortex, которая, как мы писали выше, не выдавала правильный результат ни в одном из случаев).
Если в целочисленных тестах почти двукратный прирост был скорее правилом, чем исключением, то в плане тестов с вещественными числами наблюдается в точности обратная ситуация: ощутимый разброс наблюдается практически по всем тестам. Наибольшей стабильностью обладают 177.mesa (1.95 — 2.00 раз) и 200.sixtrack (1.98 — 2.00 раз), несколько меньшей — задачи 187.facerec (1.88 — 1.97 раз) и 301.aspi (1.89 — 2.02 раз). В остальных случаях наблюдаются резкие выбросы, как в большую, так и меньшую сторону в случае одного-двух вариантов оптимизации кода (например, 171.swim, 172.mgrid, 173.applu, 178.galgel, 179.art, 191.fma3d). Наконец, встречаются и задачи с хаотическим распределением результатов, например 183.equake (от 1.43 до 1.97 раз) и 189.lucas (от 1.64 до 1.97 раз). В целом, минимальный прирост по всем задачам/вариантам оптимизации составляет всего 1.43 раз, максимальный — 2.42 раз. Очевидно, что последний результат, как и все более чем двукратные величины прироста связаны не с выигрышем при переходе к двум задачам, а с относительной «проигрышностью» исполнения исходной конфигурации — одной копии задачи. Увы, от нестабильности результатов на многопроцессорных NUMA-платформах мы, похоже, не застрахованы и в случае SRAT-совместимой ОС.
Как ни странно, усредненная оценка SPECfp_base2000 характеризуется весьма малым разбросом величин — результат попадает в интервал от 1.89 до 1.96 раз. Посмотрим, сможем ли мы достичь подобного при переходе к четырем и восьми копиям задач, запускаемых одновременно.
4 задачи
Итак, переходим к следующему случаю — одновременный запуск четырех копий тестовых задач SPEC CPU2000.
Целочисленные тесты: полученная выше картина вполне сохраняется и в случае запуска четырех копий задач. Большинство тестов по-прежнему получают прирост производительности, равный количеству копий (в данном случае — близкий к 4.00). Исключение, как и ранее, составляют задачи 181.mcf (прирост от 3.05 до 3.74 раз), 175.vpr (пониженный прирост, до 3.72 раз, в варианте -QxW). Некоторое снижение в приросте производительности показывают также задачи 197.parser, 254.gap, 256.bzip2 и 300.twolf. Прирост в среднем по всем задачам (SPECint_base2000) составляет от 3.85 до 3.94 раз, что выглядит весьма неплохо.
Как всегда, великолепную картину портят тесты с плавающей точкой. Как и в случае двух копий задач, здесь наблюдается заметный разброс результатов почти по всем задачам, за некоторым исключением 168.wupwise, 177.mesa и 200.sixtrack. Минимальный прирост наблюдается в задаче 171.swim, вариант оптимизации -QxW (2.78 раз), максимальный, как ни странно, в той же задаче, но варианте -QxN (3.99 раз). Величины прироста, превышающие теоретический максимум (4.00 раз), в данном случае не наблюдаются. Средний выигрыш в скорости по всем вещественным тестам SPECfp_base2000, как ни странно, и в этом случае отличается малой дисперсией: величины попадают в интервал от 3.46 до 3.54 раз.
8 задач
Рассмотрим, наконец, последний случай — одновременный запуск 8 копий задач, равный количеству ядер процессоров, присутствующих в рассматриваемой платформе. Заметим, что, несмотря на строгое соответствие числа задач и процессорных ядер, ожидаемая величина прироста производительности задач, так или иначе связанных с обращением в память, не может составлять ровно 8 раз ввиду того, что число присутствующих в системе контроллеров памяти вдвое меньше. Таким образом, каждые две задачи, запущенные на двух ядрах одного и того же процессора, будут неизбежно «упираться» в пропускную способность общего контроллера памяти, реализуя «SMP-подобный» сценарий. О большей выигрышности истинной NUMA-конфигурации по сравнению с классическими SMP и «SMP-подобными» двухъядерными конфигурациями мы уже писали ранее.
Тем не менее, посмотрим, что наблюдается в реальных условиях эксперимента. Заранее оговоримся, что представленные ниже результаты соответствуют не всем возможным вариантам оптимизации кода. Протестировать остальные варианты для этого случая не представлялось возможным в связи с жестко ограниченными сроками тестирования предоставленной платформы.
И вновь в целочисленных тестах наблюдается стабильный, хорошо воспроизводимый результат в большинстве задач. В ряде случаев (300.twolf) наблюдается даже более чем 8-кратный прирост в скорости, который, как мы уже писали выше, связан с большей «проигрышностью» исполнения одной копии задачи. Как и прежде, наихудший результат достигает 181.mcf, показывающая прирост всего от 4.82 до 5.56 раз. Логично предположить, что именно эта задача оказывается максимально требовательной к ПСП, тогда как остальные целочисленные задачи характеризуются высокой локальностью данных. Учитывая негативный результат, полученный в этой задаче, средняя оценка SPECint_base2000 составляет величину прироста примерно в 7.6 раз.
Как обычно, задачи с вещественными числами отличаются заметно худшим приростом производительности. Относительной нечувствительностью к количеству запущенных копий обладают 168.wupwise, 177.mesa, 200.sixtrack и 301.aspi — резонно предположить, что эти задачи, как и большинство целочисленных тестов SPEC CPU2000, отличаются высокой локальностью данных. Напротив, к задачам, наиболее требовательным к ПСП, можно отнести 179.art (прирост всего от 2.52(!) до 3.82 раз) и 171.swim (4.47 — 4.68 раз), остальные задачи, можно сказать, являются «умеренно требовательными» к ПСП. Средний прирост по всем задачам SPECfp_base2000 составляет примерно 6.0 — 6.3 раз.
Заключение
В заключение, оценим «масштабируемость» (в кавычках, т.к. говорить о масштабируемости в строгом смысле не приходится, ибо параллельный запуск нескольких копий задачи отнюдь не означает ее «распараллеливание») задач SPEC CPU2000 — наблюдаемый средний прирост скорости в зависимости от количества используемых процессоров. В скобках приведены величины прироста в пересчете на один процессор, т.е. эффективности использования данного процессора.
| Величина | 2 копии | 4 копии | 8 копий |
|---|---|---|---|
| SPECint_base2000 | 1.97 (98.5%) | 3.88 (97.0%) | 7.55 (94.4%) |
| SPECfp_base2000 | 1.92 (96.0%) | 3.50 (87.5%) | 6.21 (77.6%) |
Легко видеть, что задачи тестового набора SPEC CPU2000, как целочисленные, так и вещественные, характеризуются практически 100%-ной «масштабируемостью» при равномерном использовании двух из восьми процессорных ядер. Высокая «масштабируемость» целочисленных задач SPECint CPU2000 сохраняется и в случае использования 4 и 8 процессорных ядер, в то время как эффективность использования одного процессорного ядра вещественными задачами заметно снижается по мере увеличения количества одновременно запущенных копий задач. Как мы уже отмечали, это связано с большей требовательностью задач SPECfp CPU2000 к пропускной способности памяти, по сравнению с целочисленными тестами SPEC.
