Cluster-on-Die: властвуй и разделяй!

03 Янв 2015

Cluster-on-Die, как распределение оперативной памяти между процессорными ядрами одного кристалла

По мнению компании Intel, кластер из процессорных ядер – это именно то, что обеспечит оптимальное распределение ресурсов в мульти­про­цес­сор­ной системе. Ведь если количество вы­чис­ли­тель­ных ядер на кри­с­тал­ле постоянно увеличивается, доступ к ОЗУ становится задачей не­три­ви­аль­ной, для решения которой следует искать несимметричные ре­ше­ния. Фактически, CoD яв­ля­ет­ся логическим продолжением техно­ло­гии NUMA. Но если Non-Uniform Memory Access декларирует «хо­ро­шие ма­не­ры» для доступа процессоров из одного гнезда (сокета) к сис­тем­ной па­мя­ти, подключенной к другому процессорному сокету, кла­сте­ри­за­ция внутри кристалла призвана нормировать использование ло­каль­ных контроллеров памяти. И, как результат, – рас­пре­де­ле­ние опе­ра­тив­ной памяти между процессорными ядрами одного кристалла.

Тестирование

Оценку эффективности Cluster-on-Die проведем на платформе Intel S2600WT с двумя процессорами Xeon E5-2670 v3 частотой 2,30 GHz. Общий объем оперативной памяти составляет 64 ГБайт — это восемь регистровых модулей Kingston KVR21R15S4/8. Память будет задействована так, чтобы обес­пе­чить 4-х канальный режим доступа для ка­ж­дого сокета. В качестве дисковой подсистемы ис­поль­зу­ет­ся твердотельный накопитель NVMe емкостью 800 ГБ, модель Intel DC P3600, устанавливаемый в разъем PCI Express.

Утилита Memory Benchmark AVX256

Наилучшее представление о производительности самой современной на данный момент процессорной платфомы мы составили по результатам работы собственных бенчмарок. Впервые мы их применили в процессе знакомства с платформой Tyan S7070, где утилита Memory Benchmark AVX256 за­ре­ко­мен­до­ва­ла себя неплохим индикатором ме­т­рик.

За это время функциональность утилиты была расширена за счет режима распределенных вы­чис­ле­ний (Dis­tri­but­ed). Режим Distributed, предполагающий распределение выполняемых потоков по всем имеющимся NUMA-узлам, обеспечивает прибавку производительности по сравнению с режимом Single (Non-Distributed), в котором все по­то­ки выполняются одним NUMA-узлом. Подтверждение этому легко найти в гистограмме сводных результатов.


Рис 1. Скорость доступа к оперативной памяти в МБ/сек, полученная в среде Memory Benchmark AVX256

Напомним, что платформа Intel S2600WT – двухсокетная. Каждый из двух физических процессоров содержит два двухканальных RAM-контроллера. Оптимизация размещения данных, используемых выполняемыми потоками, состоит в таком их размещении, при котором каждый логический процессор, выполняющий заданный поток, вза­и­мо­дей­ст­ву­ет с топологически ближайшим блоком памяти. При выключенном режиме Cluster-on-Die оп­ти­ми­за­ция вы­пол­ня­ет­ся только по критерию сокетов.

При включенном режиме Cluster-on-Die оптимизация выполняется по критериям сокетов и кластеров. Кластером, входящим в состав процессора, является половина его физических ядер и ас­со­ци­и­ро­ван­ный двух­ка­наль­ный конт­рол­лер памяти. В этом режиме процессор представляется как два NUMA-узла. Вполне закономерно, что сов­мест­ное использование режимов COD и Single (Non-Distributed) приводит к падению производительности. Single за­дей­ст­ву­ет логические процессоры только одного NUMA-узла, что в данном случае означает использование ре­сур­сов про­цес­со­ра наполовину.

Для режима Distributed, распределяющего вычислительные потоки, оптимизация с использованием Cluster-on-Die обеспечивает прибавку производительности для всех операций, кроме некэшируемой записи (non-temporal write). Причины этого исключения – тема отдельного исследования. Возможно, для потоковых некэшируемых операций увеличение количества инициаторов вредно, поскольку приводит к увеличению потерь на арбитраж за счет уча­ще­ния передачи шин от одного инициатора к другому.

Стресс-тест LinX на основе Linpack

Созданный на базе библиотеки Linpack программный продукт LinX позволяет оценить эффективность вычислений с плавающей запятой. Такого рода задачи задействуют существенное количество процессорных тактов на вы­чис­ле­ния. А вот чувствительность приложения к производительности оперативной памяти (следовательно – реакции на оптимизацию размещения данных в соответствии с топологией Cluster-on-Die) зависит от того, какая доля времени уходит непосредственно на чтение и запись информации.

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

 
Рис 2Слева результат, полученный LinX при стандартном распределении потоков, справа – с использованием топологии Cluster-on-Die

Особенность результатов LinX – «волатильность» собранных данных. Поэтому в полученных отчетах главное внимание мы обратили не на абсолютные значения результатов, а на их стабилизацию, имеющую место при включении режима Cluster-on-Die.


Рис 3. Разброс значений, полученных в процессе тестирования платформы Intel S2600WT утилитой LinX

Гипотеза, объясняющая стабилизацию показаний состоит в том, что если операционная система «знает» топологию платформы, расположение обрабатываемых блоков будет оптимальным при каждом запуске операции. Поток, запущенный на заданном кластере, получит в свое распоряжение память, топологически ближайшую к «своему» кластеру. Иначе, мера оптимальности будет случайной, а разброс результатов – больше.

Вероятно, по способности вносить элемент случайности в результат, доступ к памяти становится главным фактором, если топологическая оптимальность размещения обрабатываемых данных не прогнозируема. Именно это и происходит при выключенном Cluster-on-Die, когда операционная система получает от UEFI BIOS таблицу SRAT в которой декларированы только сокеты и не декларированы кластеры. При включенном CoD, низкоуровневое ПО декларирует как сокеты, так и кластеры. Об этом информируется операционная система и приложения, использующие NUMA API для выделения памяти, всегда получают оптимальный с точки зрения топологии блок памяти. Отсюда и прогнозируемый результат.

Пакет Maxon Cinebench R15

Пакет Cinebench от ведущего производителя анимационного дизайна, визуальных эффектов, трёхмерного рисования, анимации и рендеринга фактически стал стандартным бенчмарком для оценки производительности мультипроцессорных систем. Актуальная в данный момент версия R15 позволяет выполнять тестовые задания в 256 потоков одновременно.

 
Рис 4. Слева результат (226 пунктов), полученный Cinebench при стандартном распределении потоков, справа (458 пунктов) – с использованием топологии Cluster-on-Die

Откровенно говоря, более чем двукратная разница в оценке производительности была для нас неожиданностью. Полученный результат не может быть пояснен исключительно различной скоростью доступа логических процессоров к «ближним» и «дальним» блокам оперативной памяти. Осторожно предположим, что при включении режима Cluster-on-Die, намеренно или в результате некоего побочного эффекта, произошла оптимизация доступа к кэш-памяти третьего уровня, которая является логически общей в пределах процессорного сокета, а физически разделена на блоки, ассоциированные с вычислительными ядрами.

Резюме

В большинстве тестов Cluster-on-Die не дает фантастического приращения производительности мультипроцессороной платформы. В некоторых случаях наблюдается даже заметный спад, который не стоит относить на счет погрешности измерений. Без интеллектуализации платформы дальнейшее наращивание количества процессорных ядер не даст сколько-нибудь значимого эффекта. И топология Cluster-on-Die только первый шаг в эту сторону. Насколько он удачный покажет время. Рядовой потребитель об этом узнает, если появятся кластеры из 2-х или 4-х процессорных ядер. На сегодня проходной балл в CoD-клуб составляет 10+.

Очевидно также, что увеличение нагрузки на сервер в части использования ОЗУ, сводит на нет даже самые призрачные преимущества Cluster-on-Die. Если ресурс «оптимальной памяти» исчерпан, NUMA API предоставит приложениям то, что есть в наличии, независимо от топологии. Выход из этой ситуации — наращивать объемы памяти. В обозримом будущем — от терабайта и больше.

Теги: