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.0psc 1.1psc-peak 1.1
164.gzip130314131413
175.vpr135011241152
176.gcc123915971597
181.mcf11566741056
186.crafty169420432043
197.parser148710481222
252.eon253817951864
253.perlbmk159816191728
254.gap162614031403
255.vortex244423032440
256.bzip2128312741274
300.twolf165412181553
SPECint_base2000156613931518
 ic 80psc 1.1psc-peak 1.1
168.wupwise160116361876
171.swim221020592004
172.mgrid122414221569
173.applu120113441450
177.mesa177117771930
178.galgel214624682716
179.art186416312286
183.equake150514151393
187.facerec164717471907
188.ammp119313591372
189.lucas182413491553
191.fma3d140413011359
200.sixtrack631680700
301.apsi137314441455
SPECfp_base2000148014901612

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




27 мая 2004 Г.