Тестирования процессоров с архитектурой 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 32 | pgi 32 | gcc 64 | pgi 64 | gcc, изменение, % | pgi, изменение, % | |
| 164.gzip | 1027 | 766 | 1246 | 978 | 21.32 | 27.68 |
| 175.vpr | 1086 | 1011 | 1150 | 1006 | 5.89 | -0.49 |
| 176.gcc | 1429 | 1306 | 1475 | 1248 | 3.22 | -4.44 |
| 181.mcf | 1079 | 1016 | 673 | 670 | -37.63 | -34.06 |
| 186.crafty | 1327 | 1019 | 2011 | 1521 | 51.54 | 49.26 |
| 197.parser | 1011 | 813 | 1105 | 786 | 9.30 | -3.32 |
| 252.eon | 1143 | 314 | 1963 | 387 | 71.74 | 23.25 |
| 253.perlbmk | 1533 | 1163 | 1655 | 1183 | 7.96 | 1.72 |
| 254.gap | 1150 | 955 | 1296 | 951 | 12.70 | -0.42 |
| 255.vortex | 1527 | 1479 | 1748 | 1662 | 14.47 | 12.37 |
| 256.bzip2 | 1081 | 940 | 1233 | 1011 | 14.06 | 7.55 |
| 300.twolf | 1424 | 1303 | 1148 | 1074 | -19.38 | -17.57 |
| SPECint_base2000 | 1221 | 950 | 1338 | 979 | 9.58 | 3.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.
| gcc32 | pgi 32 | gcc 64 | pgi 64 | gcc, изменение, % | pgi, изменение, % | |
| 168.wupwise | 1174 | 1519 | 1287 | 1725 | 9.63 | 13.56 |
| 171.swim | 1411 | 1910 | 1437 | 1999 | 1.84 | 4.66 |
| 172.mgrid | 798 | 1155 | 916 | 1357 | 14.79 | 17.49 |
| 173.applu | 870 | 1150 | 947 | 1292 | 8.85 | 12.35 |
| 177.mesa | 1199 | 1129 | 1749 | 1263 | 45.87 | 11.87 |
| 178.galgel | 2077 | 2636 | 26.91 | |||
| 179.art | 741 | 1344 | 1429 | 1272 | 92.85 | -5.36 |
| 183.equake | 1435 | 1174 | 1428 | 1262 | -0.49 | 7.50 |
| 187.facerec | 1416 | 2072 | 46.33 | |||
| 188.ammp | 1117 | 932 | 1368 | 1267 | 22.47 | 35.94 |
| 189.lucas | 1403 | 1415 | 0.86 | |||
| 191.fma3d | 1333 | 1459 | 9.45 | |||
| 200.sixtrack | 451 | 688 | 597 | 718 | 32.37 | 4.36 |
| 301.apsi | 784 | 1129 | 984 | 1386 | 25.51 | 22.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.0 | gcc 64 | pgi 64 | |
| 164.gzip | 1376 | 1246 | 978 |
| 175.vpr | 1084 | 1150 | 1006 |
| 176.gcc | 1585 | 1475 | 1248 |
| 181.mcf | 671 | 673 | 670 |
| 186.crafty | 2026 | 2011 | 1521 |
| 197.parser | 1047 | 1105 | 786 |
| 252.eon | 1738 | 1963 | 387 |
| 253.perlbmk | 1596 | 1655 | 1183 |
| 254.gap | 1261 | 1296 | 951 |
| 255.vortex | 2287 | 1748 | 1662 |
| 256.bzip2 | 1245 | 1233 | 1011 |
| 300.twolf | 1204 | 1148 | 1074 |
| SPECint_base2000 | 1361 | 1338 | 979 |
| psc 1.0 | gcc 64 | pgi 64 | |
| 168.wupwise | 1641 | 1287 | 1725 |
| 171.swim | 2070 | 1437 | 1999 |
| 172.mgrid | 1428 | 916 | 1357 |
| 173.applu | 1369 | 947 | 1292 |
| 177.mesa | 1777 | 1749 | 1263 |
| 178.galgel | 2510 | 2636 | |
| 179.art | 1649 | 1429 | 1272 |
| 183.equake | 1428 | 1428 | 1262 |
| 187.facerec | 1606 | 2072 | |
| 188.ammp | 1356 | 1368 | 1267 |
| 189.lucas | 1387 | 1415 | |
| 191.fma3d | 1343 | 1459 | |
| 200.sixtrack | 673 | 597 | 718 |
| 301.apsi | 1434 | 984 | 1386 |
| SPECfp_base2000 | 1493 | 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.1 | psc-peak 1.1 | |
| 164.gzip | 1303 | 1413 | 1413 |
| 175.vpr | 1350 | 1124 | 1152 |
| 176.gcc | 1239 | 1597 | 1597 |
| 181.mcf | 1156 | 674 | 1056 |
| 186.crafty | 1694 | 2043 | 2043 |
| 197.parser | 1487 | 1048 | 1222 |
| 252.eon | 2538 | 1795 | 1864 |
| 253.perlbmk | 1598 | 1619 | 1728 |
| 254.gap | 1626 | 1403 | 1403 |
| 255.vortex | 2444 | 2303 | 2440 |
| 256.bzip2 | 1283 | 1274 | 1274 |
| 300.twolf | 1654 | 1218 | 1553 |
| SPECint_base2000 | 1566 | 1393 | 1518 |
| ic 80 | psc 1.1 | psc-peak 1.1 | |
| 168.wupwise | 1601 | 1636 | 1876 |
| 171.swim | 2210 | 2059 | 2004 |
| 172.mgrid | 1224 | 1422 | 1569 |
| 173.applu | 1201 | 1344 | 1450 |
| 177.mesa | 1771 | 1777 | 1930 |
| 178.galgel | 2146 | 2468 | 2716 |
| 179.art | 1864 | 1631 | 2286 |
| 183.equake | 1505 | 1415 | 1393 |
| 187.facerec | 1647 | 1747 | 1907 |
| 188.ammp | 1193 | 1359 | 1372 |
| 189.lucas | 1824 | 1349 | 1553 |
| 191.fma3d | 1404 | 1301 | 1359 |
| 200.sixtrack | 631 | 680 | 700 |
| 301.apsi | 1373 | 1444 | 1455 |
| SPECfp_base2000 | 1480 | 1490 | 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 32 | msvc8 64 | ddk 32 | ddk 64 | msvc8, изменение, % | ddk, изменение, % | |
| 164.gzip | 1233 | 1173 | 1154 | 1023 | -4.87 | -11.35 |
| 175.vpr | 1132 | 1195 | 1183 | 1113 | 5.57 | -5.92 |
| 176.gcc | 1554 | 1534 | 1549 | 1534 | -1.29 | -0.97 |
| 181.mcf | 1152 | 769 | 1158 | 747 | -33.25 | -35.49 |
| 186.crafty | 1612 | 2021 | 1576 | 1699 | 25.37 | 7.80 |
| 197.parser | 1133 | 1089 | 1134 | 940 | -3.88 | -17.11 |
| 252.eon | 1465 | 1402 | ||||
| 253.perlbmk | 1530 | 1517 | ||||
| 254.gap | 1279 | 1261 | ||||
| 255.vortex | 1557 | 1611 | 1556 | 1433 | 3.47 | -7.90 |
| 256.bzip2 | 1206 | 1221 | 1202 | 1143 | 1.24 | -4.91 |
| 300.twolf | 1434 | 1146 | 1437 | 1103 | -20.08 | -23.24 |
| SPECint_base2000 | 1346 | 1333 |
Из этого многообразия цифр можно сделать пару выводов. Во-первых, переход на 64 бита, как минимум, не всегда полезен с точки зрения скорости. Во-вторых, свежий компилятор лучше адаптирован к 64-битной среде. Серьезно же рассуждать о скорости на основании результатов бета версий компиляторов мы не будем. Ну а то, что девять из двенадцати задач (кстати, написанных более трех лет назад) без каких-либо правок смогли быть скомпилированы и правильно работали в 64-бит режиме, на наш взгляд, является очень хорошей новостью.
Также интересно отметить, что значительное падение скорости работы 64-битного кода наблюдается в тех же тестах, что и у gcc/pgi — 181.mcf и 300.twolf.
В наборе CFP2000 только четыре теста написаны на языке C, так что рассматриваться будут только они.
| msvc8 32 | msvc8 64 | ddk 32 | ddk 64 | msvc8, изменение, % | ddk, изменение, % | |
| 168.wupwise | ||||||
| 171.swim | ||||||
| 172.mgrid | ||||||
| 173.applu | ||||||
| 177.mesa | 858 | 1652 | 811 | 979 | 92.54 | 20.72 |
| 178.galgel | ||||||
| 179.art | 1752 | 1711 | 1647 | 1391 | -2.34 | -15.54 |
| 183.equake | 1466 | 1103 | 1471 | 1046 | -24.76 | -28.89 |
| 187.facerec | ||||||
| 188.ammp | 1175 | 1440 | 1159 | 404 | 22.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, то его цель скорее обеспечивать высокую совместимость и своевременную поддержку разработчиков, чем завоевывать рекорды скорости.
