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.

 gcc 32pgi 32gcc 64pgi 64gcc, изменение, %pgi,
изменение, %
164.gzip1027766124697821.3227.68
175.vpr10861011115010065.89-0.49
176.gcc14291306147512483.22-4.44
181.mcf10791016673670-37.63-34.06
186.crafty132710192011152151.5449.26
197.parser101181311057869.30-3.32
252.eon1143314196338771.7423.25
253.perlbmk15331163165511837.961.72
254.gap1150955129695112.70-0.42
255.vortex152714791748166214.4712.37
256.bzip210819401233101114.067.55
300.twolf1424130311481074-19.38-17.57
SPECint_base2000122195013389799.583.05

Итак, с изменением скорости от перехода на 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.

 gcc32pgi 32gcc 64pgi 64gcc,
изменение, %
pgi,
изменение, %
168.wupwise11741519128717259.6313.56
171.swim14111910143719991.844.66
172.mgrid7981155916135714.7917.49
173.applu870115094712928.8512.35
177.mesa119911291749126345.8711.87
178.galgel 2077 2636 26.91
179.art74113441429127292.85-5.36
183.equake1435117414281262-0.497.50
187.facerec 1416 2072 46.33
188.ammp11179321368126722.4735.94
189.lucas 1403 1415 0.86
191.fma3d 1333 1459 9.45
200.sixtrack45168859771832.374.36
301.apsi7841129984138625.5122.76
SPECfp_base2000 1266 1446 14.22

Снова значительно выделяется результат 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 1.0gcc 64pgi 64
164.gzip13761246978
175.vpr108411501006
176.gcc158514751248
181.mcf671673670
186.crafty202620111521
197.parser10471105786
252.eon17381963387
253.perlbmk159616551183
254.gap12611296951
255.vortex228717481662
256.bzip2124512331011
300.twolf120411481074
SPECint_base200013611338979
 psc 1.0gcc 64pgi 64
168.wupwise164112871725
171.swim207014371999
172.mgrid14289161357
173.applu13699471292
177.mesa177717491263
178.galgel2510 2636
179.art164914291272
183.equake142814281262
187.facerec1606 2072
188.ammp135613681267
189.lucas1387 1415
191.fma3d1343 1459
200.sixtrack673597718
301.apsi14349841386
SPECfp_base20001493 1446

Итак, как видно по результатам тестирования, в области целочисленных вычислений 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.

  ic 8.0 psc 1.1psc-peak 1.1
164.gzip13031413 1413
175.vpr1350 11241152
176.gcc12391597 1597
181.mcf1156 6741056
186.crafty16942043 2043
197.parser1487 10481222
252.eon2538 17951864
253.perlbmk15981619 1728
254.gap1626 14031403
255.vortex2444 23032440
256.bzip21283 12741274
300.twolf1654 12181553
SPECint_base20001566 13931518
 ic 80psc 1.1psc-peak 1.1
168.wupwise16011636 1876
171.swim2210 20592004
172.mgrid12241422 1569
173.applu12011344 1450
177.mesa17711777 1930
178.galgel21462468 2716
179.art1864 16312286
183.equake1505 14151393
187.facerec16471747 1907
188.ammp11931359 1372
189.lucas1824 13491553
191.fma3d1404 13011359
200.sixtrack631680 700
301.apsi13731444 1455
SPECfp_base200014801490 1612

Наконец мы получили маленькую сенсацию — впервые по 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-бит ОС. Все результаты в этом разделе не являются официальными, в частности из-за того, что получены однократным запуском теста.

 msvc8 32msvc8 64ddk 32ddk 64msvc8, изменение, %ddk, изменение, %
164.gzip1233117311541023-4.87-11.35
175.vpr11321195118311135.57-5.92
176.gcc1554153415491534-1.29-0.97
181.mcf11527691158747-33.25-35.49
186.crafty161220211576169925.377.80
197.parser113310891134940-3.88-17.11
252.eon1465 1402   
253.perlbmk1530 1517   
254.gap1279 1261   
255.vortex15571611155614333.47-7.90
256.bzip212061221120211431.24-4.91
300.twolf1434114614371103-20.08-23.24
SPECint_base20001346 1333   

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

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

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

 msvc8 32msvc8 64ddk 32ddk 64msvc8, изменение, %ddk, изменение, %
168.wupwise      
171.swim      
172.mgrid      
173.applu      
177.mesa858165281197992.5420.72
178.galgel      
179.art1752171116471391-2.34-15.54
183.equake1466110314711046-24.76-28.89
187.facerec      
188.ammp11751440115940422.55-65.14
189.lucas      
191.fma3d      
200.sixtrack      
301.apsi      
SPECfp_base2000      

И снова мы видим, что новый компилятор обеспечивает лучшую скорость 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, то его цель скорее обеспечивать высокую совместимость и своевременную поддержку разработчиков, чем завоевывать рекорды скорости.




Дополнительно

iXBT BRAND 2016

«iXBT Brand 2016» — Выбор читателей в номинации «Процессоры (CPU)»:
Подробнее с условиями участия в розыгрыше можно ознакомиться здесь. Текущие результаты опроса доступны тут.

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.