SPEC CPU2000. Часть 20. Компиляторы Intel C++/Fortran Compiler 9.0, процессоры Intel Pentium 4 670, Pentium M 770 и AMD Athlon 64 FX-57

В середине июня компания Intel представила новую, девятую версию своих компиляторов C++ и Fortran. Новую версию компиляторов нельзя назвать принципиально иной по сравнению с предыдущей версией 8.1, ее основные особенности — это интеграция компиляторов для платформ IA-32, IA-64 и EM64T (x86-64) в единый пакет, а с точки зрения оптимизации кода — дополнительные опции для процессоров с технологией Hyper-Threading и многоядерных процессоров, в частности, спекулятивной загрузки данных из памяти в отдельно создаваемом потоке (Software-based Speculative Pre-Computation, SSP).

В настоящей статье мы рассмотрим, насколько эффективна в плане скорости новая версия компиляторов по сравнению с предыдущей на топовых (или почти топовых) одноядерных процессорах — как Intel (Pentium 4 и Pentium M), так и… AMD (Athlon 64 FX-57 — разумеется, с некоторой «доработкой» кода, о чем ниже).

Использовались следующие версии компиляторов:

• Intel(R) C++ Compiler for 32-bit applications, Version 9.0 Build 20050624Z Package ID: W_CC_C_9.0.020
• Intel(R) Fortran Compiler for 32-bit applications, Version 9.0 Build 20050624Z Package ID: W_FC_C_9.0.019

В качестве «эталона сравнения» использовался код тестов, откомпилированный ранее с помощью Intel C++ Compiler 8.1.022 и Intel Fortran Compiler 8.1.025.

Во всех случаях (компиляторы версий 8.1 и 9.0, различные варианты оптимизации кода), как обычно, использовались одинаковые общие ключи компиляции кода:

PASS1_CFLAGS= -Qipo -O3 -Qprof_gen
PASS2_CFLAGS= -Qipo -O3 -Qprof_use

Pentium 4 670

Начнем с результатов «родного» для компиляторов процессора — Pentium 4 670 (частота 3.8 ГГц) с ядром Prescott, поддерживающего все необходимые наборы инструкций и позволяющего запускать код, откомпилированный со всеми возможными ключами специфических оптимизаций: -QxK, -QxW, -QxN, -QxB и -QxP.

Но начнем, тем не менее, с неоптимизированного варианта. Сразу отметим одну важную деталь: эта версия кода, откомпилированная как предыдущей, так и новой версией компилятора, вызывала ошибки в подтестах 175.vpr и 176.gcc — независимо от типа используемого процессора. В связи с чем, мы использовали --noreportable вариант запуска тестов, позволяющий игнорировать ошибки в отдельных подтестах (--ignore_errors). Итак, целочисленные тесты. Новая версия позволяет получить некоторое преимущество в ряде подтестов (252.eon, 253.perlbmk, 254.gap, 255.vortex), которое, однако, невозможно компенсировать значительным снижением производительности 197.parser (порядка 34%!), а также 300.twolf. В результате имеем общую оценку SPECint_base2000 = 1604, на 4.6% уступающую оценке, полученной с версией 8.1 (1682). В тестах с вещественными числами новая версия позволяет получить лишь едва заметное преимущество по скорости в ряде подтестов, но и здесь не обошлось без заметного снижения скорости отдельных подтестов (13.3% в 179.art). В результате, общая оценка SPECfp_base2000 (1489) на 1.5% уступает результату, полученному с предыдущей версией (1511).

Следующий вариант оптимизации, использующий инструкции SSE (-QxK). В целочисленных тестах наблюдаем аналогичную картину — незначительное преимущество новой версии в некоторых подтестах при 1.5-кратном снижении производительности 197.parser. Тем не менее, 300.twolf в этом случае отличается не только не худшей, но и даже лучшей производительностью (2.2%). Интегральная оценка примерно на 2.5% ниже по сравнению с версией 8.1. Совсем по-другому обстоит дело в тестах с плавающей точкой — производительность большинства задач возрастает при переходе к версии 9.0, максимальный прирост наблюдается в подтестах 171.swim (7.7%) и 187.facerec (5.6%). Интегральный показатель SPECfp_base2000 на 1.3% выше по сравнению с предыдущей версией.

Что касается остальных вариантов оптимизации кода (-QxW, -QxN и -QxP), в целочисленных тестах картина оказывается похожей на вариант -QxK: по-прежнему наблюдаем 1.5-кратное падение производительности 197.parser и, как следствие, несколько меньший интегральный показатель SPECint_base2000. В тестах с плавающей точкой между указанными вариантами оптимизации наблюдаются различия — как в интегральном показателе, так и в отдельных подтестах. Так, в варианте SSE2/Willamette (-QxW) заметен прирост в 200.sixtrack (11.2%) и 187.facerec (5.0%) при значительном снижении скорости 179.art (-10.5%). По SPECfp_base2000 новая версия выигрывает всего 0.9%. Вариант SSE2/Northwood (-QxN) по общей оценке, напротив, несколько проигрывает предыдущей версии (на 0.5%), благодаря значительному падению в скорости 168.wupwise (-21.1%) и том же 179.art (-11.1%) при некотором приросте в целом ряде подтестов (178.galgel, 187.facerec, 191.fma3d и 200.sixtrack). Наконец, «родной» для Prescott SSE3-вариант -QxP выигрывает 2.6% по общему показателю благодаря увеличению производительности задач 178.galgel (7.9%), 183.equake (12.2%), 187.facerec (5.0%) и 200.sixtrack (9.5%) при практически незаметном снижении скорости выполнения немногих других подтестов (максимальном — 3.8% в 300.aspi).

Абсолютная производительность как целочисленных, так и вещественных задач в целом (по интегральным показателям) возрастает в ряду -QxK < -QxB < -QxW < -QxN < -QxP, что вполне разумно для ядра Prescott.

Pentium M 770

Переходим ко второму «почти флагману» Intel — процессору Pentium M 770 с тактовой частотой ядра Dothan 2.13 ГГц. Тесты с участием этого процессора проводились на «десктопно-мобильной» системе — материнской плате DFI 855GME-MGF с не самым быстрым чипсетом Intel 855GM, а точнее — не самой быстрой подсистемой памяти (одноканальной DDR-333).

Целочисленные тесты без оптимизации кода: наибольший прирост в новой версии наблюдается в 254.gap (~10%), наиболее сильное падение — во все том же 197.parser (по сравнению с Pentium 4, оно несколько меньше — порядка 27%). Суммарная оценка SPECint_base2000 уступает предыдущей версии в среднем на 3%. В тестах с плавающей точкой наблюдается небольшой разброс значений — как в большую, так и в меньшую сторону, однако по интегральной оценке скорость выполнения кода, откомпилированного ICC/IFC 8.1 и 9.0, практически совпадает. Удивляют весьма низкие абсолютные оценки отдельных подтестов и общего показателя SPECfp_base2000 по сравнению с результатами Pentium 4 — при несильном отставании от него по целочисленным тестам. По-видимому, это связано с требовательностью этих тестов к пропускной способности памяти, которая в случае системы на базе Pentium M с одноканальной DDR-333 заметно ниже (2.67 против 6.4 ГБ/с). Но уж точно не блоком FPU, который в Pentium M реализован не только не хуже, но и намного лучше по сравнению с Pentium 4.

Использование ключей оптимизации (для данного процессора доступны -QxK, -QxW, -QxN и -QxB) не приводит к существенному изменению картины, за исключением увеличения общей производительности (которая, заметим, возрастает именно в указанном ряду, то есть «родная» оптимизация кода под ядро Banias оказывается наилучшей и для ядра Dothan). Целочисленные тесты по-прежнему немного (примерно на 2.5%) уступают предыдущей версии (благодаря заметно сниженной производительности 197.parser при одновременном отсутствии ощутимого выигрыша в остальных подтестах), а тесты с вещественными числами практически равны ей по скорости. Но последнее вновь достигается не за счет полной идентичности результатов каждого подтеста, а за счет наличия разброса величин — как в большую, так и в меньшую сторону (особенно заметного в вариантах -QxK и -QxN — до 10% в ряде подтестов), в итоге компенсирующего самого себя.

Athlon 64 FX-57

И напоследок — самое интересное! Результаты тестов компиляторов Intel C++/Fortran Compiler 8.1/9.0 на последнем одноядерном процессоре конкурента — AMD Athlon 64 FX-57. Вы спросите, как нам это удалось? Все очень просто — для этого оказалось достаточно разобраться в алгоритме проверки типа процессора кодом приложения, откомпилированного с помощью компиляторов Intel. Схематически, выглядит она следующим образом:

1. Проверка Vendor String процессора на соответствие «GenuineIntel»;

2. Определение типа модели процессора (Pentium III/Pentium M — модель 6, или Pentium 4/Xeon — модель 15);

3. Определение наличия необходимых расширенных наборов инструкций (SSE, SSE2, SSE3).

Исходя из этой схемы и простого анализа становится совершенно очевидно, что достаточно убрать проверку №1, и код, откомпилированный Intel C++/Fortran Compiler, станет работоспособным и на процессорах конкурента — при условии, что процессор поддерживает нужные наборы инструкций. Связано это с тем, что номера моделей у процессоров Intel и AMD, к счастью, совпадают: модели 6 соответствуют процессоры класса AMD K7 (большинство из которых поддерживают SSE), а модели 15 — процессоры AMD K8 (поддерживающие SSE, SSE2, а в последней ревизии ядра E — и SSE3). Впрочем, если бы этого совпадения и не было, нам ничего не мешало бы убрать и проверку №2. Тогда работоспособность приложения зависела бы только от наличия/отсутствия в процессоре необходимых расширений.

«Исправление» бинарных файлов можно осуществлять вручную, однако для этой цели мы написали небольшую вспомогательную утилиту — ICC Patcher (скачать ее можно отсюда). Она просматривает бинарный файл на предмет «подозрительных» проверок соответствия на GenuineIntel и заменяет все эти проверки пустыми операциями NOP. Заметим, что этим патчером можно «исправлять» не только готовые exe-файлы, но и исходные библиотеки Intel C++/Fortran Compiler, в том числе для EM64T. Тогда в результате компиляции всегда будут получаться программы, работоспособные как на процессорах Intel, так и AMD. Причем, повторим, такой патчинг не является «грубым» — например, код, откомпилированный с ключом -QxP, запустится только на процессорах AMD Athlon64/Opteron с ревизией ядра E, и выдаст корректное предупреждение о невозможности продолжения работы на более ранних ревизиях ядра и на процессорах класса AMD K7.

Но перейдем к результатам тестов. Из соображений экономии времени, мы решили не перекомпилировать заново все исходники тестов с «правильными» файлами библиотек Intel, а «исправить» уже имеющиеся бинарные файлы. В связи с этим, в config-файлах тестов выставлялась опция check_md5=0, ибо нетрудно догадаться, что «исправление» исполняемых файлов изменяет их контрольную сумму.

Неоптимизированный код: в целочисленных тестах и на этом процессоре весьма заметно отставание 197.parser (27.3% — аналогичную величину мы получили на Pentium M), а также 300.twolf (13.3%), которое в некоторой степени компенсируется выигрышем в задачах 252.eon (9.3%) и 254.gap (10.2%). Общая оценка SPECint_base2000 уступает предыдущей версии компилятора примерно на 3%, что вновь весьма похоже на результаты тестов Pentium M. Тесты с плавающей точкой вновь показывают результат, близкий к предыдущей версии, который и здесь достигается не равенством скорости исполнения отдельных подтестов, а их различиями как в большую, так и в меньшую стороны, компенсирующими друг друга. В результате общий результат SPECfp_base2000 уступает всего 0.6% коду, откомпилированному ICC/IFC 8.1.

Оптимизированные варианты целочисленных тестов не вносят заметных отличий в картину, полученную на других процессорах. А именно, заметное отставание 197.parser (27-28%) сохраняется, заметный же выигрыш в отдельных подтестах не наблюдается вовсе (в порядке исключения, следует отметить задачу 253.perlbmk в варианте -QxP, отличающуюся 5.3% ростом производительности). Отставание в 197.parser обуславливает примерно 3% снижение общей оценки SPECint_base2000 во всех случаях. Что касается абсолютных величин производительности, они возрастают в ряду -QxK < -QxW < -QxN < -QxP < -QxB, то есть лучшим (но совсем ненамного, и то лишь в некоторых тестах и общей оценке) вариантом оптимизации оказывается «заточка» кода под ядро Banias. Собственно, такой результат нельзя назвать из ряда вон выходящим, учитывая родство микроархитектуры AMD K8 с Intel Pentium III/Pentium M, а не Pentium 4 (NetBurst).

Переходим к оптимизированным вариантам кода SPECfp. Как и с процессорами Intel, на Athlon 64 FX-57 во всех случаях наблюдается прирост производительности при переходе к новой версии компилятора. Относительная величина выигрыша различна (зависит от типа оптимизации), различны и, скажем так, способы ее достижения. Так, в SSE-варианте (-QxK) заметно падение в 171.swim на 8.7% (заметим, что на Pentium 4 в этой задаче наоборот наблюдался выигрыш) при увеличении скорости 172.mgrid на 10.6% и 187.facerec на 6.8%, общий прирост SPECfp_base2000 составляет 1.1%. В «старом» варианте SSE2 для ядра Willamette (-QxW, который, заметим, работоспособен на AMD K8 и без «доработки») явное лидерство сохраняется лишь в задаче 187.facerec (6.7%), общий выигрыш — всего 0.6%. «Новый» вариант SSE2 для ядра Northwood отличается не большим возрастанием SPECfp_base2000 (0.7%), но заметен различный разброс величин в отдельных подтестах (-15.1%(!) в 168.wupwise, +6.6% в 172.mgrid и +19.8% в 178.galgel). Наконец, лучший вариант оптимизации под SSE3 (ядро Prescott, -QxP) характеризуется практически полным отсутствием падения производительности (следует упомянуть разве что 3% снижение в 301.aspi) при значительном росте скорости целого ряда задач (172.mgrid на 10.4%, 178.galgel на 17.8%, 179.art на 8.3%, 183.equake на 6.5%). В результате, общая оценка SPECfp_base2000 на целых 3% выше по сравнению с предыдущей версией. Что касается эффективности кода, как мы уже отметили, она наиболее высока при использовании SSE3. Вслед за ним располагается SSE2-вариант, рассчитанный на ядро Banias (-QxB), что вновь не имеет противоречий с представлениями о микроархитектуре AMD K8, далее располагаются -QxN, -QxW и -QxK.

Выводы

Новые компиляторы Intel C++/Fortran Compiler 9.0 в «типовом» варианте компиляции кода (если таковым считать компиляцию с профилированием) демонстрируют неоднозначную картину. Результирующий целочисленный код по скорости в целом несколько (на 3-5%) уступает коду, полученному с предыдущей версией компиляторов 8.1. Значимое падение производительности наблюдается лишь в одной задаче, зато весьма весомое — от 27 до 34% в зависимости от процессора. И хорошо, если пользовательский код не окажется подобным этой задаче :).

Тем не менее, в плане вычислений с вещественными числами (где используются инструкции SSE, SSE2, SSE3) новая версия компиляторов показывает некоторое преимущество над предыдущей — правда, весьма незначительное (от 0 до 3%). Сохраняется и адекватность использования ключей оптимизации под конкретную микроархитектуру процессора (-QxP для Pentium 4/Prescott, -QxB для Pentium M/Dothan, для процессоров класса AMD K8 можно рекомендовать поэкспериментировать с ключами -QxB и -QxP).

Кстати, несколько слов о процессорах AMD. Результаты проведенного исследования показывают, что обе версии ICC/IFC — 8.1 и 9.0 — выдают на выходе код, обладающий очень хорошей (а в ряде случаев — и лучшей) производительностью на процессорах конкурента… если только его немного «исправить» :), или же «исправить» библиотеки компилятора. Было бы просто замечательно, если бы корпорация Intel, производитель процессоров и компиляторов, заменила бы нынешний вариант проверки типа процессора на более разумный — наподобие того, который использовали мы.

Такая модификация оказалась бы выгодна, прежде всего, для конечных пользователей — в этом случае, даже при использовании разработчиком ПО «автоматических» вариантов оптимизации вида -Qax*, при исполнении приложения будет выбран наиболее оптимизированный вариант кода, причем в зависимости только от наличия необходимых расширенных наборов инструкций, а не изготовителя процессора. Отметим, что один из пунктов обвинения Intel со стороны AMD заключался как раз в том, что при исполнении «автоматического» варианта кода процессоры AMD могут сильно уступать процессорам конкурента, несмотря на присутствие в них необходимых расширений.

Не менее благоприятной она оказалась бы и для разработчиков и тестировщиков ПО — отпала бы необходимость использования разных компиляторов для разных процессоров, или в «привязке» к процессорам конкретного производителя при разработке и отладке приложений.

И, конечно, в немалой выгоде оказалась бы и сама компания AMD — ибо начисто отпала бы необходимость в разработке собственного компилятора, которая вот уже долгое время находится в состоянии неопределенности :).