В этой статье мы продолжим изучать особенности процессоров AMD Opteron и обратимся к архитектуре AMD64 (ранее x86-64). Отметим, что большинство выводов можно будет перенести и на выходящий осенью Athlon64.
Все подробности о технологии AMD64 вы можете узнать на сайте www.x86-64.org. Здесь напомним ключевые из них:
- полная совместимость с современным 32-х битным кодом;
- использование 64-битных регистров и операндов;
- удвоенное количество РОН и SSE регистров:
- линейная адресация оперативной памяти;
- преодоление 4 ГБ барьера адресуемой памяти.
Основным элементом программной поддержки AMD64 является операционная система. Конечно на Opteron могут работать и современные 32-х разрядные ОС, такие как Microsoft Windows XP и RadHat Linux (а также MS-DOS, Windows 98 и другие линуксы :), однако в этом случае 64-битные расширения процессора не могут быть задействованы. Для работы 64-битных приложений обязательно нужно использовать 64-битную ОС. И если продукт Microsoft пока находится в стадии тестирования, "правильные" версии Linux уже есть в наличии. Как вы уже знаете из прошлого материала, одним из них является SLES (SuSE Linux Enterprise Server) для AMD64.
Конечно, собственно ОС без приложений никому не интересна, поскольку обычно при реальной работе она "обрастает" пользовательскими задачами.
Портирование приложений на AMD64 может быть выполнено несколькими способами. Самый простой — это (если задача поставляется с исходными кодами) просто перекомпилировать (точнее "попробовать перекомпилировать" :) ) его с использованием 64-битного компилятора. Конечно добиться высокой эффективности таким методом можно не всегда (скорее даже никогда). Поскольку, несмотря на наличие стандартов языков программирования высокого уровня, может потребоваться и тонкая настройка под новую архитектуру. В частности вопрос портирования может включать в себя проверку на использование в программе хранения ссылок в 32-битных переменных, операций с битовыми масками и двоичных сдвигов.
И конечно многие современные алгоритмы, которыми использование 64-битных переменных было бы гораздо удобнее, специально написаны для 32-битной среды поскольку она более распространена. В таких случаях для достижения высокой эффективности на новой платформе придется переписывать код.
Поэтому следующим после ОС важной частью работы с AMD64 следует признать компиляторы. От них зависит, насколько легко (или наоборот сложно) можно портировать готовые приложения на новую архитектуру, насколько полно и эффективно они будут использовать ее особенности.
В этой статье мы исследуем существующие на данный момент компиляторы для AMD64 а также сравним эффективность перехода на новую архитектуру на задачах теста SPEC CPU2000. В дальнейшем эта информация поможет нам в тестировании Opteron на реальных приложениях в том числе и в 64-битном режиме.
Конфигурация
- AMD Opteron 240 (1,4 ГГц)
- Rioworks HDAMA (чипсет AMD 8000)
- 512 МБ PC2700 Reg Transcend x 4
В тестах использовались две ОС от одного поставщика — SuSE SLES 8.1 i386 и SLES 8 AMD64.
Исследуемыми компиляторами стали:
- Intel C/C++/Fortran 7.1
- GNU gcc 3.3.1
- Portland Group Compiler Technology PGI Workstation 5.0-1
Что касается выбранных версий компиляторов, то у продукта Intel это последняя версия на время проведения тестирования. gcc сначала тестировался в версии 3.3, однако мы успели протестировать и вышедшую 8 августа версию 3.3.1. С PGI самая темная история, поскольку анонсированная в начале июля версия 5.0 имела неполный состав библиотек. В исправленной версии 5.0-1 были проблемы со скриптами. Вскоре за ней последовала 5.0-2, которая не смогла скомпилировать один из тестов SPEC CPU2000. Ну а сейчас на сайте производителя лежат еще более новые файлы неизвестной версии. Так что, исправив скрипты, мы остановились на версии 5.0-1. Отметим, что в работающих тестах 5.0-2 очень мало от нее отличается.
Вторым важным вопросом является выбор ключей оптимизации для компиляторов. Если с продуктом Intel все ясно и понятно, то gcc и PGI потребовали дополнительного исследования. Они проходили под SLES 8 AMD64 с использованием однократных запусков теста SPEC CPU2000.
Для gcc было проведено 12 тестирований с различными ключами, в результате которых был выбран вариант "-O3 -funroll-all-loops +FDO" (FDO — двухпроходная компиляция/оптимизация). В целом все варианты отличались по скорости незначительно, наибольший эффект (отрицательный) был от исключения ключа "-funroll-all-loops". Дополнительно для C++ теста 252.eon устанавливался ключ "-ffast-math", без которого тест не проходил проверку на корректность результатов. Для компиляции в 32-битный код под 64-битной ОС использовался ключ "-m32". К сожалению, выбор ключей для gcc осложнен тем, что этот компилятор в зависимости от архитектуры подбирает различные значения ключей по умолчанию. Так что использование найденных в 64-х битной среде ключей может не быть эффективным на 32-х битной. Однако использование одинаковых оптимизаций (формально, исключая используемые компилятором в зависимости от архитектуры) во всех конфигурациях вполне отвечает нашей цели о сравнении одного компилятора в разных средах.
В x86-64 вариант компилятора PGI входят на самом деле две версии — 32-х и 64-х битная. Под SLES 8.1 i386 использовалась только первая, а под SLES 8 AMD64 мы попробовали обе. Всего было протестировано пять вариантов ключей (в каждой из двух версий) компиляции и выбор остановился на "-fastsse -Mipa=fast" (что также включает двухпроходную компиляцию с профилированием). В этом случае компилировались все тесты и результаты не имели явных "провалов".
Хочу напомнить, что мы в тестах рассматриваем только base метрики теста SPEC CPU2000, что означает необходимость использования единого компилятора и одного набора ключей оптимизации (в количестве не более четырех) для каждого языка программирования. Тестирование рассматривается с позиции обычного пользователя, который не имеет возможности тратить много времени на поиск "самых лучших" опций, а на основе документации к продукту и по тестированию своей собственной программы пытается найти что-то лучшее, чем опции по умолчанию.
Скорость работы кода в разных условиях
Сначала сравним компиляторы при работе в разных ОС и режимах. Начнем с продукта Intel.
Как видно по приведенным цифрам, во всех подтестах, кроме 172.mgrid, скорость работы кода под AMD64 операционной системой меньше, чем под i386. Поскольку компилятор использовался в обоих случаях один и тот же, достаточно значительное падение скорости в подтестах 164.gzip (10%), 176.gcc (15%) и 253.perlbmk (11%) видимо объясняется использованием различных библиотек (установленных в системе). Отметим, что остальные тесты показали менее заметное отличие. В частности по всему набору CFP2000 снижение скорости не превысило 3%.
Для компилятора gcc тесты проводились в трех комбинациях:
- 32 бит ОС + gcc
- 64 бит ОС + gcc с ключем -m32
- 64 бит ОС + gcc
Во втором варианте ключ -m32 использовался для указания компилятору генерировать 32-х битный код несмотря на 64-х битную среду.
С одной стороны есть два подтеста, которые получили прибавку почти в 50% — 186.crafty и 252.eon. Однако в других подтестах есть и значительное падение — обратите внимание на 181.mcf (-25%) и 197.parser (-15%). И если первый известен как самый чувствительный к ПСП тест в CINT2000, то второй пока никак особенно себя не проявлял. Одним из объяснений такого поведения может быть факт, что в 64-х битной среде данные типов long и pointer стали 64-х битными, и это повлекло увеличение размеров структур данных и, следовательно, замедление работы с ними. Также отметим, что тест 186.crafty является единственным, который реально получает преимущество от 64-битных ОС и компилятора, поскольку оригинал использует именно 64-х битные переменные и для работы в 32-х битной среде специально адаптируется. При этом размер исполняемого кода у него единственного при переходе на SLES AMD64 сократился (причем заметно — на 18%). У остальных подтестов CINT2000 он наоборот возрос на 3-15% (и только у 181.mcf на 48%). Таким образом по итогам тестирования gcc на наборе CINT2000 можно сказать, что эффект от перехода на 64-битную среду получат только специально написанные/переписанные/адаптированные приложения. Для остальных же вполне возможет вариант падения производительности. Последний факт немного смягчается тем, что можно легко использовать компиляцию в 32-х битный код и в новой среде при этом ничего не теряя.
Напомним, что четыре отсутствующих результата относятся к тестам, написанным на языке Fortran 90, компилятор с которого не входит в пакет gcc. Как и в случае набора CINT2000, скорость работы 32-х битного кода в i386 и AMD64 версиях SLES мало отличается. Только 171.swim и 177.mesa показывают замедление на 9 и 7% соответственно. Однако поскольку и у AMD64 версии 171.swim мы тоже наблюдаем низкий результат, то скорее всего в случае этого подтеста падение вызвано именно ядром 64-х битной ОС. Что касается эффекта от перехода на 64 бита, то в случае задач, работающих с вещественной арифметикой его специально ждать не стоит, поскольку собственно разрядность вещественных переменных не меняется и такого красивого эффекта, как в 186.crafty здесь быть не может. Хотя безусловно использование удвоенного количества регистров и набора команд SSE2 может принести положительный результат (отметим здесь, что gcc в настоящий момент может использовать дополнительные наборы команд, но не умеет делать векторизацию, что уменьшает эффект от этого). Тем не менее мы видим значительный рост результатов в восьми подтестах из десяти. При этом в 179.art он составляет 94%! Это может говорить о том, что gcc достаточно эффективно использует в этих задачах преимущества архитектуры AMD64. Хотя с другой стороны, 32-х битный компилятор от Intel в этом тесте тоже показывает результат около 1100 баллов.
Компилятор от Portland Group, как мы уже говорили, существует в версиях для i386 (x86) и x86-64. При этом первая может работать и под 64-х битной средой. Таким образом мы снова получаем три комбинации.
По тестам из набора CINT2000 компилятор ведет себя аналогично gcc — также практически нет разницы по работе 32-х битного кода в разных ОС, а при переходе на 64-х битный код наблюдается значительный (91%) рост в тесте 186.crafty и падение скорости в других подтестах. Однако по сравнению с gcc все-таки 64-х битный код смотрится лучше — среднее значение прироста скорости составляет 14% по сравнению с 7% у gcc.
Что касается набора CFP2000, здесь снова нет заметной разницы в скорости работы 32-х битного кода под 32- и 64-битными ОС. А при переходе на 64 бита мы наблюдаем рост во всех подтестах, кроме 179.art. Из максимальных результатов отметим рост у 172.mgrid (51%), 177.mesa (28%), 187.facerec (24%) и 178.galgel (19%).
Сравнение компиляторов
И заключении сравним скорость работы различных компиляторов в i386 и AMD64 операционных системах на платформе AMD Opteron.
На 32-х битной платформе в наборе CINT2000 уверенно ведет компилятор от компании Intel. Он дает сбой только на тесте 176.gcc (какая ирония :). Не коммерческий gcc со времени прошлого тестирования заметно подрос и в нескольких подтестах почти догнал своего конкурента. Продукт от Portland Group к сожалению не блещет скоростью. Только в четырех (и то с натяжкой) подтестах он показывает близкие к другим участникам результаты. Отметим очень низкий балл у 252.eon, который заметно снижает интегральную оценку.
Как и ожидалось и в тестах набора CFP2000 впереди компилятор Intel. Что касается gcc, то у него есть два варианта поведения — или результат близок к лидеру, или есть значительно отставание. На этом наборе pgi немного исправился и уже в девяти подтестах наступает на пятки продукту от Intel. Отставание от него по интегральному баллу сократилось с 34% в CINT2000 до 14% в CFP2000.
При анализе следующих двух диаграмм не забудем, что компилятор Intel не использует архитектуру AMD64. Однако благодаря своей высокой эффективности он успешно соревнуется с 64-х битными продуктами.
Рывок gcc на подтестах 176.crafty и 252.eon позволил ему на 0,25% обогнать по итоговому баллу продукт Intel. В трех из двенадцати подтестов он уверенно обгоняет конкурента, а еще в двух — не уверенно :). И снова pgi на последнем месте, хотя и ему удалось прибавить в интегральной оценке 11% по сравнению с 32-х битной версией.
Пожалуй, это единственная конфигурация, где 64-х битому компилятору от pgi удается почти догнать лидера. В девяти подтестах они идут очень близко. У gcc мы наблюдаем все тот же серьезный провал на 171.swim, хотя на 179.art он вырывается вперед. Кстати он ведет и в двух других подтестах — 183.equake и 188.ammp. К сожалению отсутствие поддержки Fortran 90 не позволяет ему соревноваться на равных с другими участниками, однако и такой результат на наш взгляд очень и очень неплох.
Заключение
Все участники сегодняшнего тестирования показали, что они вполне работоспособны на широком классе вычислительных задач и под разными ОС (особенно если учесть, что исходных файлов в тестах SPEC CPU2000 более 1400). И если от продукта Intel этого вполне можно было ожидать, то другие компиляторы были новичками. (Если честно, то одной из самых больших неожиданностей была успешная сборка gcc с первого раза :) ). Изложим коротко, что мы узнали сегодня:
- работать с 64-х битным кодом можно уже сейчас, поддержка архитектуры AMD64 компиляторами gcc и pgi находится на высоком уровне;
- компилятор от компании Intel несмотря на свою формальную "враждебность" прекрасно работает и на AMD Opteron и дает лучшие результаты на широком классе задач по сравнению с другими рассмотренными компиляторами;
- рост производительности от перехода на 64-х битную архитектуру проявляется только для специально созданных/ подготовленных/ портированных программ, при этом скорее происходит "устранение издержек 32-х битного кода", чем "рост от использования 64-х битных переменных";
- для остальных задач мы также можем наблюдать рост скорости, однако он связан с другими особенностями AMD64, а не 64-х битностью;
- для некоторых задач, может наблюдаться и заметное падение производительности при переходе на AMD64, однако этого можно избежать использованием 32-х битных компиляторов;
- в сравнении 64-х битных компиляторов для задач класса CINT2000 выигрывает gcc, а для CFP2000 лидером является pgi.
По итогам можно констатировать, что архитектура AMD64 начинает свое движение в массы, второй шаг (после появления 64-х битных ОС) — создание компиляторов с поддержкой AMD64 — уже сделан. Однако следует отметить, что революционного прорыва, по крайней мере в области счетных задач, мы не наблюдаем. Будем надеяться, что с распространением архитектуры AMD64 (конечно вместе с процессорами AMD Opteron и Athlon64), задач, получающих выигрыш от нее, станет больше. По крайней мере, писать, компилировать и тестировать уже можно :)
