Вместо предисловия
В старые добрые времена, как общеизвестно, всё было старее и добрее :). Процессоров было мало, выходили они раз в полгода максимум, и сравнить их можно было, запустив на каждом Любимую Сравнительную Программу, которая по завершении четко и ясно говорила: вот у этого процессора производительность равна двадцати шести попугаям, а вот у этого — 32 попугая и одно попугайское крылышко. Но гадкие производители наплодили архитектур, технологий, и всяких прочих концепций, в результате чего сравнение быстродействия CPU превратилось в сущее мучение: одна программа предпочитает одну архитектуру, другая — другую, а для третьей вообще нет никакой разницы ни между Pentium и Celeron, ни между Athlon и Duron. Бардак, словом. Именно в этом бардаке мы и пребываем с вами сейчас.
Поэтому про Любимую Сравнительную Программу пришлось забыть, и использовать программы разные, при этом чем больше — тем (по крайней мере, теоретически) лучше. Однако теоретически — вовсе не значит на самом деле. Потому что снабдив читателя подробнейшими результатами, представленными на 101-й диаграмме, мы неизбежно ввергаем его в необходимое, но несколько несвоевременное на момент прочтения статьи состояние: в сон :). Вот между этими Сциллой и Харибдой и лежит путь современного тестера: с одной стороны — предоставить как можно более полную информацию о скорости различных процессоров в комбинации с разнообразным программным обеспечением, а с другой — не переборщить с ее объемом, чтобы читатель не бросил читать статью, не дойдя до ее конца.
Кроме того, шквальный выпуск процессоров породил еще одну проблему: каждый раз тестировать их заново — абсолютно нереально ввиду громадного их количества, если же мы хотим иметь возможность использовать в будущих статьях результаты прошлых — требуется с самого начала четко определиться с набором используемого в тестах ПО, и потом уже по возможности его не менять.
Вследствие совокупности вышеописанных причин, родились так называемые «методики тестирования», представляющие собой, по сути, фиксированные наборы программного обеспечения, тестовых данных, и опций, предназначенные для получения сопоставимых между собой результатов тестирований на протяжении достаточно длительного промежутка времени. Сегодня мы представляем вам методику, которая, по задумке автора, будет использоваться на нашем сайте для тестирования быстродействия CPU в 2005 году. И начнем мы ее представление, как всегда, с оговорок :).
Во-первых, не стоит бить в барабан, если вы вдруг не обнаружили здесь Самой Последней Версии Самой Любимой Программы, или не обнаружили данную программу вообще. Наличие общей, стандартной методики — вовсе не означает, что все остальное ПО не будет использоваться вообще. Это лишь означает, что большинство тестов будет проводиться именно в этих рамках. Никто не мешает выпустить отдельную статью, посвященную вопросам скорости отображения крестиков и ноликов в популярной игре «крестики-нолики», взяв для этого десяток другой процессоров и детально рассмотрев все возможные варианты комбинаций. Но это будет уже специализированное, «выделенное» тестирование. А вот в общих случаях набор тестов будет таким, как описано ниже.
Во-вторых, хоть в данном материале и присутствуют некие результаты, не стоит рассматривать его как материал тестовый. Фактически, все результаты, что приведены ниже — «рабочие», полученные не в процессе проведения тестов, а в процессе оценки пригодности программ для проведения тестов. Грубо говоря: если программа категорически отказывалась хоть как-то реагировать на смену процессора — она браковалась т.к. ее результаты для оценки производительности CPU непригодны. Если же разница наблюдалась — напротив программы ставилась галочка, и она записывалась в список кандидатов на включение в методику. Из прошедших предварительное тестирование кандидатов и формировался тот список ПО, который вы можете наблюдать ниже. Кроме того, в данном материале мы решили привести по возможности все полученные результаты и дать комментарии по поводу того, какие из них нам кажутся наиболее интересными. С нашей точки зрения, такой подход обеспечивает большую «прозрачность» методики: вы можете сами убедиться в том, что результаты, которые планируется отбрасывать или сводить в единое целое путем усреднения — действительно достойны того, чтобы поступать с ними именно так.
Конфигурация тестовых стендов
- Процессоры
- AMD Athlon 64 3500+ (Socket 939)
- AMD Athlon 64 3800+ (Socket 939)
- AMD Athlon 64 4000+ (Socket 939, он же в девичестве Athlon 64 FX-53)
- Intel Pentium 4 3.4 ГГц eXtreme Edition (Socket 775)
- Intel Pentium 4 560 (3.6 ГГц, Socket 775)
- Системные платы
- ASUS P5AD2-E Premium (чипсет i925XE)
- Инженерный образец платы на чипсете ATI Xpress 200P (RX480)
- Память
- 2x512 МБ PC3200 (DDR400) DDR SDRAM DIMM Corsair, 2-2-2-5
- 2x512 МБ PC2-4300 (DDR2-533) DDR2 SDRAM DIMM Micron, 4-4-4-11
- Видеокарта ATI Radeon X700 (PCI Express x16)
- Жесткий диск Western Digital WD360 (SATA), 10000 об/мин
- Windows XP Professional SP2, DirectX 9.0c
Мы не зря назвали этот раздел полусинтетикой т.к. синтетикой в чистом виде используемые в нем программы назвать, строго говоря, нельзя. «Чистая» процессорная синтетика — это низкоуровневое тестирование скорости выполнения определенных команд. В данном же случае в «синтетических» целях используются вполне прикладные, применяемые и в не-тестовом ПО формулы и алгоритмы. Так, например, CPU RightMark моделирует физику взаимодействия тел, каковая задача очень часто решается в том числе в движках компьютерных игр. Разумеется, в данном случае используется максимально оптимизированный с точки зрения быстродействия и использования дополнительных наборов инструкций код, поэтому получаемые в результате тестов скоростные показатели процессоров можно назвать несколько идеализированными, однако считать задачу чисто синтетической, не имеющей практического смысла, нельзя.
Вторая подгруппа полусинтетики — архиваторы. И тут мы имеем уже противоположный по смыслу вариант: по всем признакам, данная задача является полностью реальной, ведь мы используем ПО, которое работает на массе компьютеров. Однако формат архивируемых данных у каждого конкретного пользователя разный, в нашем же случае используется специальный тестовый набор файлов, представляющий собой некий «идеальный» вариант: много файлов одного и того же типа, причем все типы более-менее хорошо сжимаются.
1.1 CPU RightMark (RMCPU 2004B)
Напомним, что CPU RM представляет собой, по сути, два теста, объединенных в один. Модуль решателя (solver) рассчитывает физику взаимодействия тел, а модуль рендеринга (render) отображает это взаимодействие на экране. Как мы уже неоднократно убеждались на практике ранее, соотношение быстродействия процессоров различных архитектур в модулях решателя и рендеринга отнюдь не всегда дает одинаковую картину. Более того: в случае, если архитектуры достаточно сильно отличаются (к примеру, как у процессоров Intel Pentium 4 и AMD Athlon 64), различия подчас оказываются просто разительными. Рассмотрим представленную ниже диаграмму.
Хорошо заметно, что в целом архитектура AMD в модуле решателя всегда оказывается быстрее. Значит ли это, что такая же тенденция будет наблюдаться в модуле рендеринга? Совершенно не обязательно.
Наоборот, модуль рендеринга в столь же явной форме отдает предпочтение архитектуре от Intel. Связано это прежде всего с тем, что модуль рендеринга в CPU RM является многопоточным, что позволяет задействовать технологию Hyper-Threading, а она поддерживается только процессорами Intel. Разумеется, у вас может возникнуть вопрос: а почему бы не сделать многопоточным решатель? Пока что мы можем сказать одно: работа в данном направлении ведется, однако оказалось, что расчет физики намного хуже поддается распараллеливанию, чем рендеринг.
Общий результат CPU RM, как ни странно, наименее интересен. Все дело в том, что производительность решателя исчисляется сотнями кадров в секунду, а скорость рендеринга — всего лишь десятками. В таких условиях, как это всегда бывает, общую скорость определяет самое медленное звено. Грубо говоря, соотношение между процессорами на диаграмме с общим результатом почти всегда будет примерно такое же, как на диаграмме с результатами рендеринга. Поэтому нам кажется, что в диаграмме с общим баллом большой необходимости нет, если присутствуют две раздельных для решателя и модуля рендеринга.
1.2 Архиваторы
Как уже было сказано выше, мы склонны относить тестирование с помощью архиваторов к полусинтетике, а не к реальным задачам. Обе используемых программы демонстрируют примерно одинаковые предпочтения: они любят быструю память с низкой латентностью и достаточно чувствительны к объему кэша второго уровня. Кроме того, 7-zip, в отличие от RAR, умеет использовать многопроцессорность (и, как частный ее случай — Hyper-Threading). Наш тестовый набор файлов включает в себя примерно равные по размеру части, состоящие из файлов следующих типов: TXT (текстовые документы), DOC (файлы Microsoft Word), PDF (формат от Adobe, часто применяемый для распространения технической документации), BMP (несжатая графическая информация), DBF (один из все еще популярных форматов файлов баз данных), DLL (бинарные файлы).
7-zip, за счет поддержки многопроцессорности, отдает предпочтение архитектуре от Intel. Однако обратите внимание на то, как медленно он работает: на одном и том же тестовом наборе файлов, архивация с его помощью занимает в среднем в 3-4 раза больше времени, чем с помощью RAR. С другой стороны, это единственный известный нам архиватор, поддерживающий многопроцессорность, кроме того он абсолютно бесплатный, и поддерживает распаковку множества форматов.
WinRAR, постепенно становящийся стандартом де-факто для тех случаев, когда требуется большая степень компрессии, чем удается получить с помощью ZIP, не столь категоричен в предпочтениях, но в целом большее предпочтение отдает платформе AMD. Кроме того, он еще и очень быстро работает, даже с максимальным размером словаря (4 мегабайта).
Усреднять результаты двух настолько разных программ вряд ли имеет смысл, а выбрасывать одну из них не очень-то объективно (тем более что программ всего две). Поэтому в последующих статьях мы будем приводить обе диаграммы. Раздел №2: Работа с трехмерной графикой
В данном случае мы подразумеваем скорее не трехмерную графику в целом, а «трехмерное моделирование». Оно представлено тремя наиболее популярными программными пакетами: 3ds max, Maya и Lightwave. Разумеется, те, кто работает в этой отрасли профессионально, заметят отсутствие SoftImage. К сожалению, методики тестирования для данного пакета у нас пока что нет. Если это действительно интересно — напишите нам, как вы ее себе представляете (это обращение относится в основном к профессионалам, работающим с SoftImage). Быть может, iXBT обеспечит вам довольно интересный и необычный заказ ;).
2.1 3ds max 6
Несмотря на то, что у нас есть собственная методика тестирования производительности рендеринга в 3ds max, для «общей» методики мы после тщательного анализа решили использовать тест от www.spec.org. Основная причина тому: его намного более широкая функциональность. Если кто-то из вас читал статьи с тестами, сделанными по методике iXBT.com, вы наверное заметили, что измерялась там только скорость рендеринга, хотя и с целыми тремя различными render engine. Однако финальный рендеринг — отнюдь не единственная задача, скорость выполнения которой интересует людей, работающих в данном программном пакете. Скорость визуализации, вращения, быстрота реакции на действия пользователя — все это не менее интересно.
Тест от SPEC представляет собой скрипт, имитирующий действия пользователя. В нем присутствует и рендеринг тоже, однако отнюдь не только он. Поэтому с точки зрения исследования быстродействия процессоров при работе в 3ds max (а не только при рендеринге), нам он показался более предпочтительным. Разумеется, это не означает, что наша оригинальная методика будет отброшена — мы по-прежнему будем обновлять и совершенствовать ее, но использоваться она будет только в «полномасштабных» тестах, ориентированных на пользователей 3ds max, а не на «среднестатистического» пользователя, которого интересует все понемножку.
Примечание: в общем случае, если на диаграмме присутствуют баллы или кадры в секунду, лучшим результатом является больший, если же в качестве единицы измерения указано время — лучшим результатом является меньший. В том единственном случае когда лучшим является меньший балл, в статье сделана специальная оговорка (ниже по тексту).
Результаты тестовой подгруппы «рендеринг» представляют наименьший интерес т.к. для рендеринга в тесте от SPEC применяется встроенный движок 3ds max, который практически не используется профессиональными дизайнерами, работающими в данном пакете.
Интерактивная работа — как раз то, что интересует нас в тесте от SPEC более всего. Различия между процессорами нельзя назвать существенными, хоть они и присутствуют. Впрочем, это совершенно нормально: чем «реальнее» ситуация — тем, как правило, меньше разница. Это только в синтетике мы можем частенько наблюдать выигрыш в разы, или хотя бы на 30-40-50%, в реальных задачах на чистую производительность одного какого-то компонента (процессора, видеокарты, памяти, жесткого диска) накладывается скорость других устройств, поэтому при замене только одного из них эффект не столь велик. В целом, можно констатировать преимущество AMD.
Поскольку основное внимание в данной статье уделяется описанию методики тестирования, а не результатам, упомянем здесь способ подсчета общего Composite балла: в него входят результаты двух предыдущих подгрупп (рендеринг и интерактивная работа) с соотношением: 20% от рендеринга и 80% от интерактива. Таким образом, интерактив имеет подавляющее преимущество, что дает возможность достаточно легко предсказать результаты: в подавляющем количестве случаев победителем в общем зачете будет победитель интерактива.
Нам кажется, что в связи со всем вышеизложенным в последующих статьях имеет смысл приводить только результаты интерактивного подтеста т.к. рендеринг с помощью встроенного движка, как уже было написано выше, малоинтересен, а общий балл ввиду неинтересности рендеринга и малой его доли в подсчете финального результата представляет собой лишь слегка «смазанный» вариант результата интерактивного теста.
2.2 Maya 6
Последняя версия пакета трехмерного моделирования от Alias|Wavefront — 6-я, однако тест SPECapc for Maya на момент разработки методики был доступен только для версии 5. Что, впрочем, совершенно не помешало ему корректно выполняться на Maya 6, чем мы и воспользовались. На настоящий момент уже доступен «родной» тест для Maya 6, и впоследствии, мы, конечно, будем использовать его.
С точки зрения организации тестового процесса, тест от SPEC для Maya очень похож на тест для 3ds max — он также представляет собой скрипт, имитирующий различные действия пользователя. Правда, в данном случае отсутствует подтест финального рендеринга, но это даже к лучшему. Бенчмарк выдает по окончании четыре результата: производительность графической подсистемы, подсистемы ввода/вывода, процессора, и общий балл.
Несмотря на то, что производительность графики, по идее, должна зависеть от видеокарты (которая во всех наших тестах была одинакова), различия между некоторыми CPU заметны даже в нем. Впрочем, учитывая то, что скорость графической подсистемы на x86 PC традиционно очень сильно зависит от особенностей реализации драйверов, а код драйверов исполняет процессор, объяснение этого феномена лежит на поверхности. К слову, заметьте: результаты мощных процессоров почти идентичны, только более низкоскоростные CPU не дают видеокарте полностью использовать свои возможности.
Честно говоря, из объяснений на сайте SPEC, не очень хорошо понятно, что подразумевается под производительностью подсистемы ввода/вывода (I/O). Если только скорость считывания данных с диска — то нас данный параметр не интересует совершенно. Однако и тут мы наблюдаем различия между некоторыми процессорами, поэтому пока не будем сбрасывать со счета данный подтест.
Разумеется, лучше всего разницу в производительности между процессорами показывает подтест, который так и называется: «CPU». Однако и тут есть вопросы: получается, что Athlon 64 3800+ ничем не отличается по скорости от Athlon 64 4000+. Такое теоретически может быть, ведь частота у них одинаковая, но все-таки несколько странно, что пакет трехмерного моделирования не смог извлечь пользы из увеличенного в 2 раза объема кэша второго уровня. Впрочем, также можно предположить, что результаты «сгладила» не самая мощная видеокарта. Мы проверим эту гипотезу в будущих тестах, заменив ATI Radeon X700 на X800.
Общий балл подсчитывается из трех предыдущих, при этом весовые коэффициенты распределяются следующим образом: графика — 70%, процессор — 20%, подсистема ввода/вывода — 10%. Легко заметить, что наиболее интересующий нас подтест представлен в общем результате относительно слабо. Учитывая это, а также то, что какое-то (пусть и незначительное) влияние CPU мы все равно наблюдаем во всех подтестах без исключения, представляется целесообразным в дальнейшем приводить две диаграммы для Maya: с результатами подтеста CPU, и общий балл.
2.3 Lightwave 3D 8
К сожалению, интерактивного теста для Lightwave 8 нам найти не удалось, поэтому в данном случае придется ограничиться тестированием скорости рендеринга относительно сложной сцены. Также будет полезно упомянуть, что Lightwave по-прежнему отказывается автоматически «понимать» количество CPU, и число потоков для модуля рендеринга приходится выставлять вручную. Правда, результаты внутренних тестирований показали, что можно поступать еще проще: всегда выставлять данный параметр на максимум (8 потоков). На производительность однопроцессорных систем увеличение количества потоков рендеринга сколько-нибудь заметного влияния не оказывает.
Комментировать в результатах особенно нечего, предпочтения программы вполне очевидны. Поскольку разница между процессорами различных архитектур наблюдается, тест можно отнести к категории полезных и интересных, и задействовать в методике. Соответственно, поскольку результат всего один, вопроса о том, какую диаграмму выбрать, не возникает. Раздел №3: Работа с растровой графикой и допечатная подготовка
Основным тестом в данном разделе является скрипт для Adobe Photoshop CS (8), разработанный в нашей тестовой лаборатории. Он включает в себя наиболее часто повторяемые действия: фильтры Blur и Sharpen, изменение цветовой модели (RGB -> CMYK -> Lab), эффекты освещения, вращение изображения, изменение размера, операции типа «Transform». Действия производятся над реальной фотографией, снятой с помощью цифровой камеры. Также по просьбе достаточно большого количества читателей в раздел добавлено тестирование с помощью Adobe Acrobat Distiller — преобразование формата PS в PDF. В качестве исходников используются несколько реальных статей, сверстанных для одного из номеров журнала iXBT.com.
3.1 Adobe Photoshop CS (8)
Скрипт Blur включает в себя обработку изображения с помощью фильтров Gaussian Blur, Motion Blur и Radial Blur. Последний фильтр представлен наименьшим количеством операций т.к. он занимает наибольшее количество времени. Параметры фильтров варьируются в достаточно широких пределах.
Скрипт Color самый простой: изображение последовательно преобразуется из исходного RGB 8 bit/channel в CMYK 8 bit, Lab 8 bit, Lab 16 bit, CMYK 16 bit, RGB 16 bit, и потом снова RGB 8 bit. Данная последовательность повторяется достаточно большое количество раз, чтобы минимизировать влияние погрешности измерений на результат.
Скрипт Lighting оперирует с одиночными и множественными источниками света всех представленных в Adobe Photoshop типов: Spotlight, Directional, Omni, в различных комбинациях.
Скрипт Rotate последовательно вращает изображение по часовой стрелке и против на различные «неудобные» значения градусов (3.3, 6.6, 9.9, и так далее).
Скрипт Sharpen обрабатывает изображение с помощью фильтра Unsharp Mask с различными параметрами, каждый из которых варьируется в достаточно широком диапазоне.
Скрипт Resize последовательно (ступенчато) увеличивает изображение более чем в 3 раза (по каждой оси), а потом уменьшает его в 3 раза по отношению к оригиналу. Действие повторяется достаточно большое количество раз чтобы свести к минимуму погрешность измерений.
В скрипте Transform используется циклически повторяющаяся комбинация из всех доступных в Adobe Photoshop видов операции Transform: Scale, Rotate, Skew, Distort, Perspective.
Общий балл выводится как среднее геометрическое от времени выполнения всех семи скриптов. Здесь следует заметить, что хоть формально формат данных в этом случае сохраняется, но воспринимать их следует уже как чистые «баллы» т.к. среднее геометрическое от нескольких интервалов времени уже не имеет практически никакого отношения к времени исполнения конкретных скриптов.
По результатам, общему и подтестов: легко заметить, что увлеченно и долго комментировать можно практически каждый, и разница в производительности между различными процессорами и архитектурами изменяется от подтеста к подтесту достаточно непредсказуемым образом. Однако давайте вспомним, что в настоящей статье мы обсуждаем не тестирование процессоров с помощью Adobe Photoshop, а общую методику тестирования производительности CPU. Поэтому несмотря на то, что каждый подтест по-своему интересен, в рамках «всеохватных», а не специализированных материалов, скорее всего, следует ограничиться диаграммой с общим результатом. Что, впрочем, вовсе не означает, что на основании созданных тестовых скриптов нельзя сделать некий специальный материал, посвященный углубленному тестированию быстродействия CPU исключительно в Adobe Photoshop.
3.2 Adobe Acrobat 6 Distiller
Тем, кто использует данную программу в своей профессиональной деятельности, вряд ли стоит объяснять, для чего она предназначена. Тем же, кому ее название ни о чем не говорит, объяснять придется довольно долго. Поэтому для последних вкратце укажем, что Distiller осуществляет преобразование данных (файлов) из одного формата в другой, и эта операция при допечатной подготовке является практически неизбежной в большинстве случаев, достаточно частой, и отнимает ощутимое количество времени. То есть представляет собой классическую задачу, скорость выполнения которой вызывает интерес у пользователей.
Различия между процессорами заметны и местами довольно существенны, что, собственно, и является одним из основных требований, предъявляемых к тесту. Практическая востребованность Distiller определенной категорией пользователей также сомнению не подлежит. Все предпосылки для включения данного теста в стандартную методику налицо. Раздел №4: CAD/CAM
Данный раздел является для нас принципиально новым, поэтому мы не особенно торопились с включением в него большого количества программ. Собственно, на данный момент в него входит всего один программный пакет: SolidWorks 2003. Использование относительно старой версии пакета обусловлено тем, что SPEC.org пока не выпустила тестового пакета для более поздних. Впрочем, развитие ПО в данном секторе идет относительно медленно, поэтому ждать кардинальных различий в процессорных предпочтениях между относительно рядом стоящими версиями вряд ли стоит.
Для тех, кто вообще незнаком с данной разновидностью ПО, вкратце опишем область его применения. В основном это конструирование различных сложных устройств: двигателей, автомобилей... в общем-то — вплоть до космических кораблей. SolidWorks — достаточно «уважаемый» машиностроительный CAD, и нам кажется, что результаты тестирования процессоров с его помощью будут востребованы специалистами, работающими в данной области.
4.1 SolidWorks 2003
Традиционно для многих тестов SPECapc, тестовый скрипт имитирует работу пользователя и выдает по завершении четыре результата: общий балл, производительность графической подсистемы, подсистемы ввода/вывода, и процессора. Стоит заметить, что для SPECapc for SolidWorks 2003 система оценки скорости в баллах сохранена, но наилучшим является меньший результат.
Как по предыдущей диаграмме, так и по результатам тестирования быстродействия графической подсистемы, заметно, что пока существенной разницы между процессорами не наблюдается. Хотя, с другой стороны, мы еще не дошли до процессорного подтеста...
...А вот как раз в нем (что радует!) различия выражены намного более сильно. Впрочем, наверное, стоит попробовать установить более мощную видеокарту: быть может, тогда разница станет еще более ощутимой.
Загадочный I/O подтест... также демонстрирует существенную разницу! Причем особенно ярко она выражена при сопоставлении Athlon 34 3500+ с Athlon 64 3800+. Не очень понятно, с какой стати — ведь изменялся в данном случае лишь процессор, все остальное, включая чипсет системной платы, оставалось в неприкосновенности. Наверное, следует предположить, что под производительностью подсистемы ввода/вывода SPEC подразумевает все-таки не только винчестер, иначе расхождения в результатах труднообъяснимы.
Пока что наиболее приемлемым кандидатом на включение в будущие статьи выглядит диаграмма с результатами процессорного подтеста. Хотя стоит попробовать установить более мощную видеокарту, и если результаты графики станут более информативными, быть может, имеет смысл приводить и общий результат. Раздел №5: Кодирование медиаданных
В данном разделе объединено все что связано с кодированием видео- и аудиоинформации, то есть классическое преобразование WAV -> MP3, а также сжатие видеоданных посредством наиболее распространенных кодеков. Быть может, кому-то ограничение аудиочасти одним лишь MP3-кодеком LAME покажется неоправданным сужением тематики, однако давайте смотреть правде в глаза: подавляющее количество пользователей кодирует именно MP3 (а не OGG, и не WMA), и делает это именно с помощью LAME. В видеоразделе мы обеспечили большее разнообразие: используются целых четыре кодера: DivX, XviD, Windows Media Video 9, и MPEG2-кодер Mainconcept MPEG Encoder.
5.1 Кодирование аудиоданных
Старый, добрый LAME... Ввиду громадного количества пресетов, и не меньшего количества их ярых поклонников, мы пошли по самому простому пути: исследуется кодирование с максимально возможным качеством: 320 kbps CBR, q=0.
Ранее мы уже выяснили, что установка параметра q=0 приводит к резкому взлету «кэшелюбивости» у последней версии данного кодека, что и подтверждают результаты на диаграмме, приведенной выше (наилучший показал Pentium 4 eXtreme Edition с 2 МБ кэша третьего уровня).
5.2 Кодирование видеоданных
Не включить в тестирование на скорость кодирования DivX было бы странно... вот мы его и включили. Особенных сюрпризов новая версия не преподнесла
А вот XviD, чем старше он становится, тем больше похож по картине производительности на своего коммерческого собрата DivX.
…И Windows Media Video 9 тоже демонстрирует очень похожую картину…
…Вы будете смеяться, но кодирование MPEG2 с помощью Mainconcept MPEG Encoder ее тоже не меняет!
Таким образом, мы наблюдаем одну диаграмму, которая, безусловно, заслуживает отдельного рассмотрения ввиду несколько другой ориентации, чем все остальные (кодирование аудиоданных с помощью LAME), а также четыре диаграммы с результатами различных видеокодеков, довольно сильно похожие друг на друга. При таком раскладе нам представляется «концептуально правильным» сводить все четыре диаграммы для видео в одну (по среднему геометрическому), и приводить результаты отдельных кодеков только в том случае, если их поведение вдруг стало сильно отличаться от рассмотренного выше.
Именно так мы решили назвать раздел, самую большую часть которого составляют… игровые тесты. В принципе, ничего непонятного тут нет: тестируя производительность компьютеров с помощью «демок», мы тестируем именно скорость визуализации, и ничего более. Никакой «искусственный интеллект» игры, даже если он в ней присутствует, в процессе проигрывания демки не задействуется, движения персонажей предопределены раз и навсегда, никакой «собственной воли» у них в рамках тестового прогона нет. Соответственно, нагрузка ложится в основном на ту часть движка игры, что «скармливает» данные видеоподсистеме, и еще, быть может, на обсчет физики (если он вообще предусмотрен игровым движком). Именно по этой причине говорить о том, что тестирование с помощью демок отражает реальную производительность компьютера в реальном игровом режиме, в целом, неверно: в частности, совершенно не задействуется ИИ. Впрочем, ИИ работает только в Single Play Mode, так что с известной натяжкой можно считать что демки отражают реальную скорость при игре по сети.
Однако не только игры попали в данный раздел. В самом его конце к играм сиротливо пристроился SPEC viewperf — тест производительности при визуализации трехмерной графики в профессиональном инженерном ПО с использованием OpenGL API. Собственно: а почему бы и нет? Чем демка для DOOM3 или FarCry принципиально отличается от демки для 3ds max или Pro/ENGINEER? А ничем, кроме используемого для визуализации движка, если разобраться. Поэтому именно тут SPEC viewperf самое место. Однако начнем все-таки с игр…
6.1 Современные трехмерные игры
Для всех игр мы протестировали по два режима: с разрешением 640x480, 32-битным цветом, и слабенькими настройками качества, а также 800x600 с опять-таки 32-битным цветом и средними настройками качества картинки. Внутреннее тестирование показало, что использование в рассматриваемых играх более графически сложных режимов (к примеру, 1024x768x32 с высоким качеством графики) очень сильно нивелирует влияние процессора на производительность, и поэтому малоинтересно с точки зрения основной задачи тестовой методики.
Особенного влияния настроек графики и разрешения на сравнительную скорость разных систем не замечено… но что более печально — существенной разницы между даже достаточно сильно различающимися по производительности CPU не заметно вообще! Можно, конечно, грешить на слабую видеокарту, но пока DOOM3 совершенно не смотрится в качестве подходящего бенчмарка для процессора.
В Far Cry все сложнее т.к. для него есть целых четыре штатных демки. Вкупе с двумя разрешениями и установками качества графики, всего имеем восемь (!) диаграмм. Здесь мы приводим все — для того, чтобы вы могли воочию убедиться в том, что…
…Что от уровня к уровню картина производительности совершенно не меняется. Диаграммой выше вы видите среднее геометрическое для «нижних» настроек графики по всем демкам, и она как две капли воды похожа на четыре предыдущих. Есть ли какие-то изменения при смене разрешения на более высокое и увеличении качества?…
Нет, никаких изменений не наблюдается, разве только разброс результатов стал чуть меньше, что вполне объяснимо: увеличилось влияние видеокарты. Таким образом, в качестве олицетворения производительности процессора при визуализации трехмерной графики с помощью движка Far Cry вполне может выступать сводный результат четырех демок, снятый при разрешении 640x480x32 с низкими настройками качества. Различия между процессорами он демонстрирует наиболее хорошо. А только они нас и интересуют, не будем про это забывать.
Painkiller — несомненно, одна из самых «вкусных» для процессорного теста игр, причем именно новый бенчмарк C5L2 (более старый C5L1 от процессора зависит очень мало, это было выявлено в результате внутреннего тестирования). Ошеломляет результат Pentium 4 eXtreme Edition — на фоне Pentium 4 3.6 ГГц на ядре Prescott, результаты P4 XE производят эффект ушата холодной воды. А что еще нужно тестеру как не побольше таких вот интересных «ушатов»? :)
Для тестирования в Unreal Tournament 2004 мы использовали две «сторонние» (не входящие в комплект поставки) демки: Ons_dria и Primeval. По количеству событий, происходящих на экране, количеству участников и спецэффектов на единицу времени, они намного более напряженные и зрелищные, чем стандартные. Однако существенной разницы между процессорами мы все равно не наблюдаем, разве что традиционный «замыкающий» большинства игровых диаграмм (Prescott) на этот раз отстал еще сильнее. Впрочем, именно благодаря Prescott разница оказывается не настолько мала, чтобы исключить игру из методики. Пожалуй, сводная диаграмма для низкого разрешения достойна включения в статьи.
Также, быть может, имеет смысл подводить небольшой «игровой итог» в виде сводной диаграммы со средним результатом по всем четырем (или трем, если DOOM3 не оправдает надежд) тестам. Хотя нужность ее, честно говоря, под большим вопросом. Ждем ваших отзывов…
Отдельно о наболевшем: о Half-Life 2. Разумеется, мы впоследствии рассмотрим вопрос о введении данного игрового теста в методику, тем более что реальный кандидат на вылет из нее присутствует (DOOM 3). Однако практика показывает, что использование для тестирования игр версии 1.0 (т.е. первый релиз, без патчей) чаще всего не оправдывает себя т.к. после выхода патчей ситуация с производительностью может здорово измениться. Поэтому имеет реальный смысл подождать как минимум первого патча, а еще лучше — двух-трех, и уже потом вводить данный игровой тест в стандартную методику.
6.2 Пакеты трехмерного моделирования
В случае со SPEC viewperf включения в статьи достойна только диаграмма с общим баллом по тесту. Уж поверьте, как говорится, на слово — мы просто не захотели загромождать статью лишними диаграммами, их и так набралось ни много ни мало 50 штук :).
Итак, вот мы и рассмотрели предлагаемую для использования в 2005 году методику тестирования производительности современных процессоров. Разумеется, она скорее всего будет модифицироваться с выходом новых программ и обновленных версий старых, однако хотелось бы надеяться на то, что имеющийся на данный момент костяк останется: разрабатывался он довольно долго, большинство пожеланий пользователей мы постарались учесть, и перерабатывать сейчас методику «с нуля» — занятие, которое, как говорится, «врагу не пожелаешь». С нашей точки зрения, методика получилась вполне адекватная: большинство ресурсоемких областей задач не оставлены без внимания, различия в производительности между процессорами достаточно хорошо заметны, сводные диаграммы — информативны. В ближайшее время (если после выхода статьи и ее обсуждения читатели не заметят в предложенной методике каких-нибудь откровенных «ляпов»), мы выпустим первое сводное тестирование с более весомой подборкой CPU, причем не только самых топовых, но и более «народных» моделей. Перечислим еще раз тот набор диаграмм, который мы считаем оптимальным после рассмотрения результатов всех тестов:
- CPU RightMark 2004B
- Модуль решателя
- Модуль рендеринга
- Архиваторы
- 7-zip
- WinRAR
- Трехмерная графика
- SPEC for 3ds max 6, интерактивный подтест
- SPEC for Maya 6, подтест CPU или общий балл
- Рендеринг в Lightwave 3D 8
- Растровая графика и допечатная подготовка
- Тестовый скрипт для Adobe Photoshop 8, общий балл
- Преобразование PS -> PDF с помощью Adobe Acrobat Distiller
- CAD/CAM
- SPEC for SolidWorks 2003, подтест CPU или общий балл
- Кодирование медиаданных
- Кодирование с помощью LAME
- Сводный результат для DivX/XviD/WMV9/Mainconcept MPEG Encoder
- Визуализация трехмерной графики
- DOOM3, низкое разрешение (под вопросом)
- Far Cry, сводная диаграмма по 4-м демкам для низкого разрешения
- Painkiller, бенчмарк C5L2, любое разрешение (можно взять и 800x600x32)
- Unreal Tournament 2004, сводная диаграмма по 2-м демкам для низкого разрешения
- SPEC viewperf 8.01, сводная диаграмма по всем подтестам.
Итого: 17 диаграмм. Как нам кажется, этого с одной стороны вполне достаточно для адекватной оценки производительности CPU, а с другой — не настолько много, чтобы читатель заснул, не дочитав статью до конца :). Ждем ваших отзывов!
