SPEC CPU2000. Часть 15.
AMD64 и 64-битный код. Вторая попытка.

Тестирования процессоров с архитектурой AMD64 проводятся уже достаточно давно. И практически после каждой статьи мы получаем множество откликов, упрекающих нас в «нечестности» по отношению к 64-х битному режиму этих моделей.

Действительно, кроме пары синтетических тестов и пакетов нам реально нечего предложить. Даже попытка обратиться к документу от самой AMD со списком 64-битного ПО не привела к положительному результату - оказалось, что большинство указанных пакетов либо перманентно находятся в состоянии разработки, либо про существование версий на 64 бита не знают даже их авторы :). Тем не менее, пара реальных приложений нашлась, и мы попробуем из них что-нибудь сделать, но уже в других статьях. А сегодня еще раз обратимся к тестированию компиляторов под AMD64, тем более, что именно от них существенно зависит появление пользовательских приложений под эту архитектуру.

Отметим, что мы уже пробовали тестировать процессоры AMD Opteron под 64-х битной ОС и именно с 64-х битными компиляторами. В первый раз особого впечатления на нас это не произвело, хотя и рост скорости исполнения некоторых подтестов SPEC CPU2000 внушал оптимизм.

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

Тесты проводились на следующей платформе:

• процессор AMD Athlon 64 FX-53
• материнская плата ASUS SK8V (чипсет VIA K8T800)
• два модуля памяти Corsair PC3200 Registered ECC 512 МБ (тайминги 2-3-2-5)

Linux

В тестах ОС Linux использовались дистрибутивы SuSE 9.0 Pro и SuSE 9.0 Pro for AMD64. Был установлен стандартный набор пакетов для рабочей станции. После этого были обновлены ядра и компиляторы gcc (с помощью готовых rpm от SuSE). Итоговые версии:

• платформа i386: ядро 2.4.21-209, компилятор 3.3.2-26
• платформа x86-64: ядро 2.4.21-199, компилятор 3.3.2-29

Кроме стандартного компилятора gcc/g77/g++ в тестах участвовал компилятор Portland Group (PGI) версии 5.1-3 (от 14 января 2004 года).

Пакет gcc не включает в себя компилятор Fortran 90, и мы не можем получить официальные результаты SPECfp_base2000. Поэтому приводятся только результаты десяти подтестов из четырнадцати. А для PGI нам удалось получить полностью официальные данные.

При проведении тестов использовались следующие ключи оптимизации:

• gcc/g77/g++: -O3 -funroll-all-loops +PGO (-fprofile-arcs/-fbranch-probabilities)
• pgi: -fastsse -Mipa=fast (два прохода компилятора для использования IPA)

Поскольку цифр достаточно много и нас больше интересует изменение результата при переходе на 64 бит, то в этот раз для представления результатов ограничимся таблицами.

Начнем, как всегда, с набора CINT2000.

Итак, с изменением скорости от перехода на 64 бита картина очень неоднозначная. Хотя интегральный показатель и вырос, результаты отдельных подтестов демонстрируют заметное «брожение».

Для компилятора gcc, по сравнению с прошлым тестированием (версия gcc 3.3.1), мы видим, что в целом стало лучше: падение скорости отмечается теперь только в двух подтестах, по сравнению с четырьмя для gcc 3.3.1, и по интегральному показателю скорость возросла на 9,6% (gcc 3.3.1 - на 4,8%). А вот новая версия PGI скорее стала хуже: рост интегрального показателя составил всего 3%, по сравнению с 11% для версии 5.0-1, и «провалы» в 181.mcf и 300.twolf стали больше.

Однако следует учесть и то, что прошлое тестирование проходило на процессорах Opteron 240 с частотой 1,4 ГГц и памятью DDR333.

Теперь обратимся к CFP2000.

Снова значительно выделяется результат 179.art на компиляторе gcc - использование 64-бит режима практически удваивает результат (правда, отметим, что это скорее обусловлено низким результатом в 32-битном режиме, чем высоким в 64-битном). В большинстве остальных подтестов наблюдается рост скорости, в среднем он составляет 25,4%. По сравнению с прошлым тестированием отметим исправление показателей у 171.swim - теперь, вместо падения на 8,6%, есть рост на 1,8%. Так что и на наборе CFP2000 видно общее улучшение скорости 64-битного кода для компилятора gcc.

Что касается pgi, то, как и в прошлый раз, есть падение в 179.art, а на остальных задачах виден рост. По интегральному показателю он составляет 14,2% (для версии 5.0-1 было 12,5).

Удалось протестировать и нашумевший продукт от компании PathScale – PathScale EKO Compiler Suite версии 1.0. Хотя и только в 64-х битном режиме, поскольку генерация 32-х битного кода у него в настоящий момент находится в состоянии альфа версии. Правда отметим, что для некоторых подтестов SPEC CPU2000 ключ "-m32" используется в официальной публикации для peak результатов. Что касается ключей оптимизации, то использовался поставляемый компанией конфигурационный файл. Он практически совпадает с используемым для публикации результатов на сайте SPEC. Отметим, что производитель поступил очень мудро и поставил в тестовую станцию четыре модуля памяти и использовал режим чередования, что позволило получить значительный рост результатов (как мы и показали еще прошлым летом). К сожалению, сейчас мы всегда используем только два модуля, так что нужно просто учесть, что резерв еще есть :). Для сравнения используем результаты 64-х битных версий gcc и pgi.

Итак, как видно по результатам тестирования, в области целочисленных вычислений psc достойно соперничает с gcc, а для вычислительных задач с вещественной арифметикой конкурирует с pgi. Первый блин, безусловно, не получился у PathScale комом. Так что AMD64 обрела хорошую поддержку в лице этого производителя.

Как это часто бывает, после написания части про PathScale выясняется, что только что вышла новая версия (1.1) компилятора :), так что мы решили отложить публикацию на несколько дней, чтобы добавить и его результаты (тем более что список багфиксов достаточно велик, и многие из них относятся к задачам SPEC CPU2000). Для версии 1.1 компилятора использовался и новый конфигурационный файл, входящий в поставку пакета. Кроме исправления ошибок, в 1.1 поддержка 32-х битного кода перешла из стадии альфы в стадию беты. Тестовый запуск в этом режиме показал, что все практически все задачи SPEC CPU2000 (за исключением 178.galgel, исполнение которого занимало неопределенное время) скомпилировались и прошли контроль качества. Результаты, в среднем, были в 1,5-2 раза меньше, чем при 64-х битах. По сравнению с версией 1.0 результаты незначительно изменились – по SPECint_base2000 рост составил 2,4%, по SPECfp_base2000 получилось падение на 0,2%. Интересно, что для peak запуска теста 178.galgel используется математическая библиотека от AMD ACML 2.0. Видимо, именно это позволило ему увеличить результат почти на пять процентов.

Обычно мы не используем peak показателей в наших тестах. Одной из причин этого является то, что на наш взгляд "подгон" настроек отдельных подтестов скорее является уделом производителей компиляторов и процессоров, поскольку большинство пользователей редко занимается этим. Попробуйте, например, догадаться, что именно "-O3 -ipa -LNO:fusion=2:interchange=OFF:blocking=OFF:ou_prod_max=10:ou_max=5:prefetch=2 -OPT:IEEE_arith=1:ro=3:unroll_size=0 -TENV:X=4 -WOPT:mem_opnds=on:retype_expr=on:val=0" дадут лучший результат :). Ну а если уж дело дошло до тонкого подбора многочисленных опций, то для достижения максимального результата на пользовательской программе часто переписывается код (например, по результатам исследования анализатором) и поэтому peak показатель на синтетических тестах SPEC CPU2000 скорее является метрикой "возможностей компилятора" и не может служить для точного сравнения скорости процессоров. Однако в этот раз, чтобы порадовать поклонников AMD :), приведем в таблице и peak показатели продукта от PathScale. Ну а сравнивать его в этот раз будем с самым быстрым компилятором для IA32 от компании Intel, работавшим под ОС Windows XP.

Наконец мы получили маленькую сенсацию – впервые по SPECfp_base2000 компилятор от Intel проиграл своему 64-х битному сопернику (точнее, это верно и для psc версии 1.0). К этому факту можно относиться по-разному. Например, считать, что наступила эра 64-х битных вычислений и всем нужно срочно бежать туда :), ну а можно и более спокойно проанализировать ситуацию и сказать, что у пользователей появился еще один повод попробовать использовать AMD64 на своих задачах. Тем более что отрыв не такой уж и большой, особенно учитывая, что Intel тестировался под другой ОС, а под Linux результат может немного отличаться (см. например эту статью).

Windows

В качестве 64-битной ОС выступала версия Windows XP AMD64 от февраля 2004 года (билд 1069). Компиляторов же удалось найти целых два: из DDK для Windows 2003 Server билд 3790 от марта прошлого года (версия 14.00.2207.0) и из превью Visual Studio «Whidbey» (версия 14.0.30702.27) (в таблицах обозначен как msvc8).

К сожалению, цифр в этом разделе еще меньше - во-первых, использовался только компилятор с языков C/C++, а во-вторых, некоторые тесты не получилось скомпилировать/запустить для 64-бит ОС. Все результаты в этом разделе не являются официальными, в частности из-за того, что получены однократным запуском теста.

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

Также интересно отметить, что значительное падение скорости работы 64-битного кода наблюдается в тех же тестах, что и у gcc/pgi - 181.mcf и 300.twolf.

В наборе CFP2000 только четыре теста написаны на языке C, так что рассматриваться будут только они.

И снова мы видим, что новый компилятор обеспечивает лучшую скорость 64-битного кода по сравнению с прошлогодней версией. Однако и он в тесте 183.equake показывает заметное снижение результата.

Сравнивать результаты MSVC с компиляторами под Linux на наш взгляд не имеет особого смысла. Если интегральные показатели SPEC CPU2000 еще как-то можно было сравнить, то отдельные подтесты в этом ключе совершенно не интересны и будут сильно «натянуты» (например - в 179.art MSVC показывает лучший итог, а в 32-битном режиме 177.mesa заметно отстает от gcc).

Выводы

Сначала стоит заметить, что по интегральным оценкам все протестированные программы (кроме PathScale в CFP2000) проигрывают 32-битному компилятору от Intel. Уже одно это сильно ограничивает «радость» от местами возросшей скорости.

То, что результаты всех компиляторов просто невозможно как-то сравнить, говорит скорее об их сырости (и конечно о том, что код используемых задач не очень хорошо адаптирован к AMD64, и без этой адаптации эффекта, скорее всего, не будет). Но, безусловно, есть и прогресс в развитии стандартных компиляторов для платформ Linux и Windows. Однако в этот момент от компиляторов скорее ожидается просто работоспособность, чем максимальная эффективность получаемого кода.

Будущее (хороших :)) компиляторов для AMD64 все еще туманно. С одной стороны Intel объявила о поддержке 64-битного режима и его команд в своих процессорах, с другой возможна ситуация, когда ее компиляторы будут работать только с процессорами Intel.

Если же говорить о протестированных продуктах, то на стороне gcc, безусловно, его лицензия, и продукт будет продолжать развиваться. PGI имеет относительно сильные позиции на рынке компиляторов для кластерных систем. Продукт PathScale сразу с первой версии смог показать достойные результаты, и мы надеемся, что в дальнейшем он будет успешно соперничать с именитыми конкурентами.

Что касается платформы Windows и ее стандартного компилятора от Microsoft, то его цель скорее обеспечивать высокую совместимость и своевременную поддержку разработчиков, чем завоевывать рекорды скорости.