SPEC CPU2000. Часть 19. EM64T в процессорах Intel Pentium 4


Мы уже пробовали оценить производительность версии 64-битного процессора от Intel в тестах SPEC CPU2000, однако в тот раз это был серверный Xeon, который хотя и интересен массовому пользователю, однако все-таки ориентирован на другой рынок.

С выходом 600-й серии процессоров Intel Pentium 4 у многих, конечно, появился вопрос: «А чьи 64 бита лучше?». К сожалению, ответы на такие внешне простые вопросы не всегда также просты. Очень много зависит от параметров, которые остались за кадром — от операционной системы, компилятора, общей архитектуры систем, и, конечно, стоимости.

Таким образом, на мой взгляд, корректной постановкой вопроса будет более общий вариант: «Производительность системы с железом Ж под операционной системой О и компилятором К на задаче З». Конечно, формально за 64-битной архитектурой остаются ее классические «много памяти одному процессу» и больший набор более широких регистров, однако тестам SPEC CPU2000 до первого момента нет никакого дела, а второй сильно зависит уже от компилятора.

В этом материале мы проанализируем производительность процессора Intel Pentium 4 660 на платформах Linux и Windows. Первая  является 64-битной уже давно, и именно на ней чаще решают «большие» вычислительные задачи. А Windows XP x64 затесался сюда, как способ оценить, чего можно ждать от 64-х бит под этой ОС. Специальных приложений под нее пока, мягко говоря, не видно (пожалуй, только FarCry засветился специальным обновлением, от которого, правда, толку пока тоже нет).

Intel Pentium 4 660

На нашем сайте уже был опубликован подробный обзор этой модели на популярных приложениях под 32-битной ОС. Кратко выводы получились такие: в сильно усредненном понятии «производительность» Pentium 660 идет наравне с Athlon 64 FX-55.

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

Первое ощущение – он греется… Безусловно, об этой проблеме написано уже немало, и по большому счету можно сказать, что это проблема системы охлаждения, но… Выданный редактором раздела штатный кулер просто не справился… Интересно, что никакой проблемы внешне заметно не было. Но при этом работала технология TM2, и результаты тестов были значительно ниже – потери скорости составляли до 18%. Единственным способом узнать, не входит ли процессор в тротлинг, является использование специальных утилит типа RMClock. Так что советую всем заинтересованным лицам внимательнее отнестись к проблеме перегрева.

В следующих тестах кулер от Intel был заменен на внешне практически такой же Foxconn CMI-775-1N, и тесты прогонялись одновременно с работой RMClock. С этим кулером все стало заметно лучше — процессор не перегревался, однако дополнительные 80- и 120-миллиметровые вентиляторы в корпусе заметно шумели.

После долгих поисков был найден рекомендуемый многими авторами Zalman 7700Cu, одновременно материнская плата была заменена с Albatron PX925XE Pro-R на ABIT Fatal1ty AA8XE, и память Corsair XMS2 поменяли на более «продвинутую» XMS2 Pro.

И на некоторое время воцарилось счастье. Однако у новой платы разъемы для дополнительных вентиляторов были в неприличных местах, и я, понадеявшись на мощь «Заламана», не подключил их. Но не тут-то было. При одновременной компиляции тестов тремя разными компиляторами система порадовала меня сообщением, что «мне стало горячо, и я, пожалуй, выключусь»…

Заметим, что на этом комплекте результаты оказались заметно ниже. Далее были безуспешные попытки что-то там подправить в BIOS. В итоге Albatron вернулся, а память осталась. При этом, несмотря на формально совпадающие тайминги, новая память выдавала в двух подтестах результаты на 5-6% меньшие. Поскольку мы на рекорд в этой статье не идем, то было принято решение остановиться на этой связке. «Но осадок остался» (С).

SuSE 9.2

Новый (по крайней мере, для наших тестов) релиз популярного дистрибутива от компании Novell производит как всегда очень приятное впечатление – удобная программа установки, хороший комплект программ, ядро 2.6, дистрибутивы для двух архитектур (IA32 и AMD64/EM64T) на одном диске (правда, он теперь двухслойный, так что дополнительная резервная копия обойдется заметно дороже). Отмечать совместимость с EM64T, думаю, уже нет смысла – SuSE еще с апреля прошлого года поддерживает 64-битную архитектуру  от Intel. Все протестированные компиляторы также отлично работают на этом дистрибутиве. Отметим, что производителем сейчас предлагается уже версия 9.3 этого продукта.

Что касается упомянутого выше сообщения, все оказалось достаточно просто — ОС написана согласно правильным стандартам и поддерживает современные технологии ACPI.  Так что при достижении установленных в BIOS 85 градусов система официально и без особого шума просто выключилась (предварительно записав в логи причину такого своего поведения).

Пожалуй, единственное, что не работало «из коробки» — мониторинг температур и вентиляторов, однако это может быть связано и с BIOS материнской платы, а настройка дополнительных пакетов мониторинга не входила в наши планы.

Конфигурация ПК

Итак, окончательное тестирование проходило в следующей конфигурации:

  • процессор Intel Pentium 4 660 (3,6 ГГц, 2 МБ L2, Socket 775);
  • материнская плата Albatron PX925XE Pro-R;
  • два модуля памяти Corsair CM2X512A-4300C3PRO (работала как DDR2-533 с таймингами 3-3-3-6);
  • операционная система SuSE Linux 9.2, версии для i386 и x86-64;
  • операционные системы Windows XP Pro SP2 и Windows XP Pro x64.

Охлаждением занимался Zalman 7700Cu в паре с 80- и 120-миллиметровыми корпусными вентиляторами (работающими на пониженных оборотах). От видеокарты и жесткого диска результаты тестов SPEC CPU2000, как мы знаем, не зависят, но для полноты картины укажем, что это были ATI Radeon X600 и Seagate Barracuda V SATA. Питание обеспечивал блок от FSP мощностью 460 Вт.

Тесты под Linux

Поскольку тестирование проходило не один день, а авторы компиляторов очень любят обновлять их версии, то было принято решение остановиться на одном наборе версий, а новые сборки использовать уже в следующих статьях (тем более что опыт показывает, что скорость кода при небольшом изменении версий меняется не сильно).

В итоге получился следующий набор уже известных продуктов:

  • GNU gcc 3.3.4 (32/64-битные версии из поставки ОС);
  • PGI Workstation 5.2-4 (32/64-битные версии);
  • Pathscale EKO Compiler Suite 2.1-280 (64-битная версия);
  • Intel Compilers 8.1 (C/C++ 8.1.030, Fortran 8.1.026);
  • Intel Compilers 8.1e for EM64T (C/C++/Fortran 8.1.026).

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

gcc/g77 — классический компилятор в Linux-системах. По определению с рождения умеет работать с AMD64/EM64T. Вопрос об эффективности хотя и стоит в приоритетах у разработчиков, однако, в любом случае после совместимости. Компилятора с Fortran 90 в комплекте нет, поэтому получить полные результаты в тестах с плавающей запятой на нем нельзя.

Продукт The Portland Group достаточно популярен (в узких кругах :) ), в частности, благодаря поддержке OpenMP и MPI. Это один из первых коммерческих компиляторов с поддержкой технологии AMD64. Сегодня уже доступна версия 6.0-2. В ней появилась поддержка PGO, однако на тестах SPEC CPU2000 она приводит к падению скорости исполнения кода. Но исследования продолжаются, и я надеюсь, что эта проблема решится в следующих версиях, а пока продолжим использовать билд 5.2.

Pathscale — относительно молодой продукт, сразу создававшийся с ориентацией на 64-битные вычисления на архитектурах AMD64/EM64T. Он достаточно быстро развивается (за год существования номер версии возрос до 2.1), однако с некоторыми версиями бывают мелкие проблемы типа не реализации некоторых библиотечных функций. Как и в прошлый раз, поскольку это приложение не имеет 32-битной версии, мы вне конкурса приведем кроме base результатов еще и peak. Отметим, что в базовый конфигурационный файл (входящий в поставку) для peak запусков мы внесли пару изменений — теперь используется ACML (да… забавно… ACML на процессоре Intel… посмотрим, что получится) версии 2.6.0 и выключено использование 3DNow! в двух тестах.

Продукты от Intel заслуженно воспринимаются как лучший продукт от «автора Pentium». Конечно, кому как не производителю процессоров знать все тонкости их внутренней архитектуры и писать эффективный компилятор. Отметим, что это единственный коммерческий компилятор, поддерживающий SSE3 в ядре Prescott сегодня.

Как обычно, «выжимания» максимума производительности не проводилось, используются base-метрики и, по возможности, одинаковые ключи оптимизации для всех подтестов. Тонкости касаются в основном настройки «портирования» для различных ОС. Конфигурационные файлы могут быть высланы желающим по e-mail. Основные ключи оптимизации были следующие:

  • Gcc: -O3 -funroll-all-loops -fprofile-arcs/-fbranch-probabilities;
  • PGI: -fastsse -Mipa=fast;
  • Pathscale: -Ofast -fb_create fbdata/-fb_opt fbdata;
  • Intel: -fast -prof_gen/-prof_use.

Обращаем внимание, что и в этот раз некоторые результаты нужно отнести к «оценочным» («estimated» по терминологии SPEC), поскольку используются бета и внутренние версии компиляторов. Однако от официальных они, скорее всего, сильно отличаться не будут (по крайней мере, я такого за последнее время не встречал).

 Linux 32Linux 64Сравнение
64 vs. 32 (%)
 gccic8.1pgi5.2gccic8.1pgi5.2path2.1path2.1
peak
gccic8.1pgi5.2
164.gzip8861152881100012169501086108212,95,67,9
175.vpr10681223989109511801002105210912,5-3,51,3
176.gcc17232102158517041899151416771676-1,1-9,7-4,5
181.mcf1499197713957809257557761494-48,0-53,2-45,9
186.crafty103213478321502162511221351143445,520,634,9
197.parser1071145789511551219831106712047,8-16,3-7,2
252.eon8851873221140422512661442150058,620,220,4
253.perlbmk1413210314481575219913871564172911,54,6-4,2
254.gap144719441389155419301374162016097,4-0,7-1,1
255.vortex1586256015161896278616212460259719,68,87,0
256.bzip21075130810981265141311361232120717,78,03,5
300.twolf14541664146914211662126012951623-2,3-0,1-14,2
SPECint_base2000123116761038132616141015133014787,7-3,7-2,2
            
168.wupwise12502768150712383230169820662244-1,016,712,7
171.swim188125852784200125692758270827046,4-0,6-0,9
172.mgrid881161214328641854169213241467-2,015,018,2
173.applu914158316811006162317641612161110,12,55,0
177.mesa913151911021560204412321506177670,934,611,8
178.galgel 34613157 3544339725353002 2,47,6
179.art990362919491828582418193945466584,760,5-6,7
183.equake21002141179319512485199621612083-7,116,111,3
187.facerec 20781653 2210225223782518 6,436,2
188.ammp83199111301198142613221099116944,243,917,0
189.lucas 22321960 2245206321792168 0,65,3
191.fma3d 14141452 1725162412191227 22,011,9
200.sixtrack34364561848063466155953140,0-1,77,0
301.apsi7791336119084513631317118612458,52,010,7
SPECfp_base2000 18141554 2076171117071803 14,410,1

По тестам CINT2000 видно, что если бы не приличный «провал» на 50% на задаче 181.mcf, то итоговые оценки были бы заметно лучше. По ранним тестированиям мы помним, что этот подтест очень зависит от скорости работы с оперативной памятью. И в данном случае, видимо, что-то «ломается» для 64-битного кода. Возможно, перестает хватать кэша, или его особенности в 64-битном режиме не позволяют работать эффективно. В пользу этого варианта говорят и результаты в 181.mcf для двухпроцессорных конфигураций.

Обратите внимание, что наиболее «интересным» переход на 64 бит в тестах CINT2000 выглядит для некоммерческого компилятора gcc. И в CFP2000 он тоже в принципе не плох.

Продукт от Intel, как и ожидалось, продолжает показывать самые высокие результаты на  процессорах одноименной компании. Радует тот факт, что для CFP2000 у него нет ни одного сильного снижения скорости кода. С CINT2000, правда, ситуация похуже. Однако по всем задачам этого набора в абсолютном зачете он лучший. Что касается отдельных тестов с вещественной арифметикой, то он проиграл в четырех из них продуктам от Portland Group и Pathscale. Странно выглядит проигрыш в 171.swim, поскольку этот тест сильно зависит от скорости работы с памятью, а этот момент Intel должен знать лучше всех.

PGI продолжает «радовать» нас низкими результатами в нескольких подтестах CINT2000, что не позволяет ему соревноваться на равных по интегральному показателю. Однако и в остальных задачах он совсем не блещет, недотягивая даже до gcc. С вещественной арифметикой у него получше, и компилятор идет в среднем на равных с Pathscale, а в четырех задачах выигрывает у Intel.

Pathscale EKO Compiler Suite, несмотря на свою молодость, успешно конкурирует с классиками в лице Intel и PGI. И если в CINT2000 он занимает ровную позицию между Intel и PGI, то в восьми из 14 тестов CFP2000 он проигрывает PGI, а в двух выигрывает у Intel. Несмотря на ориентацию на 64-битные платформы, пять тестов в peak-конфигурации используют ключ –m32 (включая злополучный 181.mcf), и это означает, что не все задачи сейчас хорошо ложатся на новую архитектуру. Кстати, использование ACML дало прибавку почти в 20% в тесте galgel.

Что касается общей оценки перехода на 64-бит на платформе Intel, то, пожалуй, для задач класса CFP2000 это имеет смысл. Пусть прирост и не такой большой, но он есть – рост интегрального показателя SPECfp_base2000 на 14 и 10% для компиляторов Intel и Portland Group может быть существенным для определенных пользователей. Тем более что полная совместимость с 32-битным кодом позволит ничего не потерять (напомним, что по нашим тестам скорость 32-битного кода в 64-битной ОС практически не отличается от скорости работы под «родной» системой).

Windows XP Pro x64 Edition

Удалось протестировать и пару компиляторов в недавно вышедшей 64-битной версии операционной системы от Microsoft. Для 64-битных библиотек использовался апрельский PSDK (3790.1830). В качестве оппонента выступала обычная Windows XP Pro SP2.

Использовались компиляторы:

  • Intel Compiler 8.1 (C 027, Fortran 030);
  • компилятор из состава Microsoft Visual Studio 2003 (13.10.3077);
  • Intel Compiler 8.1e for EM64T (C 018, Fortran 017);
  • 64-битный компилятор из состава Microsoft PSDK (14.00.40310.41).

Следует отметить, что и Portland Group представила бета-версию компилятора для x64 версии Windows, однако это (пока) только Фортран, и нам не удалось быстро получить хоть какие-то цифры, так что подождем релиза.

 Windows 32 битWindows 64 битСравнение 64 vs. 32 (%)
 ic8.1msvcic8.1msvcic8.1msvc
164.gzip1209972121310570,38,7
175.vpr1248106812331094-1,22,4
176.gcc2044 19211349-6,0 
181.mcf2096157420571000-1,9-36,5
186.crafty135211491589141717,523,3
197.parser149811191411786-5,8-29,8
252.eon22651154248714859,828,7
253.perlbmk18981507206914989,0-0,6
254.gap1942169119151660-1,4-1,8
255.vortex2913171928811580-1,1-8,1
256.bzip213201152140812096,75,0
300.twolf17911418179114480,02,1
SPECint_base20001737 177012711,9 
       
168.wupwise2798 3081 10,1 
171.swim2569 2534 -1,4 
172.mgrid1621 1862 14,9 
173.applu1596 1672 4,8 
177.mesa15888692095153531,976,7
178.galgel3661 3662 0,0 
179.art450120866118196935,9-5,6
183.equake212019372441178515,1-7,9
187.facerec2017 2180 8,1 
188.ammp135211431298903-4,0-21,0
189.lucas2278 2235 -1,9 
191.fma3d1576 1721 9,2 
200.sixtrack651 642 -1,4 
301.apsi1358 1350 -0,6 
SPECfp_base20001915 2069 8,0 

Напрямую сравнивать с прошлым тестированием под Windows результаты нельзя, поскольку в тот раз использовался процессор от AMD. Однако отметим, что в целом переход на 64 бита для компилятора Intel можно описать словами «стало чуть лучше», а вот для Microsoft результат очень сильно зависит от приложения, и по сравнению с Intel «гуляния» в обе стороны заметно больше.

Из интересных моментов отметим «не падение» результата в подтесте 181.mcf по сравнению с тестами под Linux. Возможно, здесь сыграло роль различие в моделях работы с памятью (размер ссылок и int/long).

Что касается сравнения Linux vs. Windows, то для компиляторов Intel результаты хотя и близки, но скорость под Windows выше. Особенно если сравнивать 32-битные версии.

Итоги

Развитие 64-битных платформ идет своим чередом. С выпуском процессоров с технологией EM64T «неожиданно» оказалось, что все, что было наработано для AMD64, работает и на ее близнеце. Выход Windows x64 должен еще прибавить ускорение этому процессу, тем более что программная поддержка уже есть и выполнена на достойном уровне.

Под Linux, если речь не идет о коммерческих проектах на Fortran, вполне можно остановиться на стандартном компиляторе gcc. Однако если речь идет о гонке скоростей, то без коммерческих продуктов не обойтись. И для платформы Intel очень напрашивается (причем обосновано) компилятор именно этой компании. Новые версии компиляторов от Portland Group и Pathscale вполне могут поспорить с ним по скорости. Но, видимо, больше ориентированы на работу в составе высокопроизводительных вычислительных кластеров, а тест SPEC CPU2000 это «померить» не может. Так что при выборе компилятора для «больших» систем стоит учитывать не только скоростные показатели, но и поддержку современных технологий, программных интерфейсов и стандартов.

Результаты тестирования под Windows очень противоречивы. Очень сложно сделать прогнозы на то, как реальные программы будут работать под новой системой. С одной стороны, по целочисленным приложениями все не очень плохо (хотя с MSVC — это уж как повезет), а с другой — на серьезное обновление парка оборудования эта причина совсем не тянет. САПР и подобные большие приложения будут использовать компилятор от Intel, и будет им счастье. Но представить себе игру, написанную на Фортране и скомпилированную IC, очень сложно. Скорее всего, трудоемкие части кода будут писать на 64-битном ассемблере (тем более что у «правильного» ПО уже все нужные фрагменты на asm), а остальное — уж как получится компилировать MSVC.



Благодарим российское представительство компании Novell
за предоставленный для тестирования дистрибутив SuSE Linux




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

iXBT BRAND 2016

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

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

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

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