Итак, мы представляем вам новую методику тестирования iXBT.com. Наши постоянные читатели, быть может, отметят разницу в её наименовании: если ранее мы представляли данный продукт в качестве «Методики тестирования производительности процессоров от iXBT.com» — то теперь официальное название изменилось на «Методику тестирования компьютерных систем»: процессоры, вроде бы, приравнены ко всем остальным компонентам. Это и так, и не так. С одной стороны, — мы согласились с тем очевидным фактом, что в производительности современных компьютеров центральный процессор играет одну из доминирующих ролей — но лишь одну из них, не более того. С другой стороны, — мы не можем отрицать того факта, что в современной архитектуре центральный процессор (CPU) по-прежнему остаётся центральным — то есть его роль не изменилась, и он по-прежнему оказывает влияние на производительность всех подсистем современного персонального компьютера. В условиях этого противоречия (кто-то, наверное, вспомнит термин «диалектическое единство противоположностей»), нам остаётся лишь один компромиссный вариант — признать одновременно два факта: 1) что производительность готовой (целостной) компьютерной системы зависит не только от центрального процессора; 2) что её производительность зависит от центрального процессора настолько сильно, что его влияние глупо игнорировать, и даже возможно рассматривать в некоем отрыве от всех остальных — как самостоятельную, пусть и не совсем самодостаточную величину.
Нынешняя методика тестирования, соответственно, призвана максимально отделить друг от друга три независимых характеристики:
- Производительность (скорость, быстродействие, etc.) центрального процессора (CPU).
- Производительность (и прочие синонимы, см. выше) иных подсистем.
- Производительность всей компьютерной системы, как единого целого.
Разумеется, процессорную ориентированность методики тестирования мы вряд ли смогли бы забыть настолько быстро: в данной версии она традиционно осталась доминирующей. Однако общий вектор кардинально изменился, и в последующих версиях методики его влияние будет ощущаться всё больше и больше: курс взят на разработку универсальной методики тестирования производительности компьютерных систем, в которой влияние центрального процессора, разумеется, было бы учтено — но сообразно его влиянию на быстродействие компьютера в целом, а не как самодостаточного фактора. Иными словами: мы постепенно перестанем давать вам ответы на простой, но уже в достаточной степени бессмысленный вопрос — какой процессор лучше?, Но мы постараемся дать адекватный ответ на вопрос более сложный — какой процессор лучше конкретно для меня, учитывая мои конкретные задачи и предпочтения относительно других составляющих системного блока?Основные принципы нашего подхода к тестированию
Почему ресурсоёмкие приложения?
У тестирования производительности компьютерных комплектующих и готовых систем методом выполнения ресурсоёмких задач, есть свои традиционные противники. Они задают не такой глупый вопрос — зачем нужны эти тесты? О чём скажут среднестатистическому пользователю, так сказать, случайному прохожему с улицы, их результаты, если он не знает даже названий половины используемых вами программных пакетов (а второй опрошенный не будет знать другой половины)? Казалось бы, весьма убедительная постановка вопроса: и действительно — кому всё это нужно, и нужно ли вообще? Мы попытаемся ответить подробно, поэтому ответ будет состоять из трёх частей.
- Во-первых, не стоит перебарщивать с усреднением, иначе можно дойти до абсурда: найти среди случайных прохожих человека, профессионально занимающегося конструированием автомобилей, действительно довольно сложно — однако наличие вокруг достаточно большого количества автомобилей, невольно наводит нас на мысль, что где-то эти люди всё-таки существуют. Разумеется, чрезвычайно любимый многочисленными маркетологами среднестатистический пользователь действительно ставит перед собой очень мало таких задач, при которых быстродействие компьютера оказывает решающее влияние на скорость выполнения которых, а не его самого. Именно поэтому мы полностью согласны с мыслью о том, что нынешнего среднестатистического пользователя очень мало волнуют проблемы производительности. И пусть они его не волнуют! Мы, вроде бы, не затаскиваем людей с улицы под дулами автоматов читать свои исследования. Видимо, наши материалы как-то находят на просторах интернета те самые конструкторы, которых на улицах не найти. Таким образом: мы не пытаемся удовлетворить всех.
- Во-вторых, практика показывает, что удачность или неудачность продукта, с потребительской точки зрения (то самое голосование кошельком), в подавляющем большинстве случаев напрямую кореллирует с его реальными техническими данными — и то, что большинство потребителей о них даже понятия не имеют, на данную закономерность никак не влияет. Иными словами: сравнение продуктов на основании грамотно проведенного тестирования, и результаты опроса субъективного мнения о продуктах достаточно репрезентативного количества пользователей — чаще всего дают одинаковый или очень похожий результат. Однако в данном случае тестирование имеет ряд неоспоримых преимуществ: оно проводится существенно легче и быстрее, чем социологический опрос, к тому же, его можно провести сразу после выхода продукта на массовый рынок (а то и до него) — когда соответствующей базы пользователей, успевших сформировать своё мнение, просто не существует. Таким образом: даже если вам непонятно, как работает методика оценки — это вовсе не означает, что она не работает.
- Действительно, теоретически возможно разработать методику тестирования, основанную на иной парадигме, нежели использование ресурсоёмких приложений. Помнится, один из наших авторов такую альтернативную парадигму даже описал. И, кстати, — никто и никогда не говорил, что мы отрицаем полезность воплощения данной идеи. Однако, как нетрудно заметить, нынешняя версия классической» методики — уже четвёртая (а были и не только целочисленные версии), и несмотря на это, поводов для улучшения по сравнению с предыдущей было найдено предостаточно. Поэтому вряд ли стоит торопиться с поспешными анонсами недоделанной и сырой альтернативы. Обсуждать нечто стоит лишь тогда, когда продукт дозрел до стадии обсуждения.
Группирование тестов по общим признакам
Объединение приложений в группы по неким признакам «родства» практикуется нами уже давно, равно как и публикация в теле статьи только диаграмм с общими баллами по группам. Подробные результаты по каждому тесту выкладываются в виде отдельной таблицы, ссылка на которую присутствует в статье. Причина такого подхода очевидна: результатов очень много. Так, например, после тестирования по методике, описанию которой посвящён данный материал, получается 88 различных результатов. Представляете себе статью, в которой 88 диаграмм? Вот и мы с трудом. И, тем более, трудно представить человека, который дочитает такую статью до конца.
Таким образом, объединение тестов в группы, и, соответственно, объединение результатов в некий общегрупповой балл, при использовании более-менее подробной методики (предполагающей достаточно большое количество тестов) — практически неизбежно. Однако от аккуратности планирования объединяющих групп напрямую зависит, что получится в результате: или просто несколько групп результатов вместо одной большой группы, или нечто стройное, логичное и осмысленное. Во всех предыдущих версиях методик мы старались объединять приложения либо по принципу принадлежности к одному из общеизвестных (и общеупотребимых) классов программного обеспечения, либо по сходству выполняемых ими задач. В данной версии методики мы решили полностью отказаться от построения групп по первому признаку и сосредоточить внимание именно на задачах. Кроме того, логичным продолжением вышеописанной идеи является отказ от раздельных общих баллов по домашнему и профессиональному сегментам: если пользователя интересует производительность в определённом классе задач — он, надеемся, будет в состоянии узнать нужную ему группу по её наименованию. Если его интересует пресловутая «средняя температура по больнице» — то вполне логично, если она будет представлена одним значением.
Групп в 4-й версии методики стало меньше: их всего 11 (в предыдущей версии было 14). И это при том, что количество используемого ПО и бенчмарков — увеличилось. Такого эффекта удалось достичь именно за счёт более продуманного формирования групп. Впрочем, мы учли и интересы тех, кто не сможет сразу привыкнуть к новой нотации, или даже не захочет её принимать: теперь таблица с результатами имеет три закладки: сырые результаты тестов, сводная таблица в новом стиле, и сводная таблица в старом стиле. Пусть каждый читатель сам решает, как ему удобнее. Далее, мы подробно опишем группы и идеи нового стиля, так как со старым вы, скорее всего, и так хорошо знакомы.Группы ПО и используемые тесты
Вначале имеет смысл указать ПО, общее для всех тестов в методике. Это:
- Microsoft Windows Vista Ultimate x64 + SP1;
- NVIDIA Graphics Drivers x64 Vista 182.08.
Драйверы чипсетов, процессоров (при наличии необходимости в них) и прочих комплектующих, используются самые новые из доступных на момент проведения конкретных тестов.
Группа 1. 3D-визуализация.
Новая группа, однако, достаточно хорошо знакомое ПО. Традиционно, (и уже достаточно давно) мы используем три теста в трёх наиболее именитых пакетах для работы с трёхмерной графикой: Autodesk 3ds max, Autodesk (ранее Alias|Wavefront) Maya и NewTek Lightwave.
Некоторые наши читатели резонно отмечают, что популярность последнего мало сравнима с первыми двумя, однако мы придерживаемся той точки зрения, что у Lightwave есть пусть и не очень большая, но зато стабильная доля рынка (и тенденций к её уменьшению вроде не наблюдается), есть свои уникальные особенности — и поэтому исключение данного пакета из методики тестирования привело бы к, так сказать, сужению её кругозора, и к тому же наверняка огорчило бы пользователей Lightwave. Согласитесь, ничего хорошего ни в том, ни в другом нет. К тому же, забегая вперёд, отметим: в данной версии методики, тест с участием Lightwave стал значительно интереснее, чем во всех предыдущих.
Наши постоянные читатели наверняка помнят, что результаты при тестировании в каждой из вышеупомянутых программ делятся на два типа: скорость интерактивной работы и скорость рендеринга (отдельно только у Maya — скорость процессороёмких операций, исключая рендеринг). Первый тип нагрузки (интерактивный) достаточно критичен к скорости процессора и видеосистемы (для вывода изображения на экран используется либо Direct3D, либо OpenGL) — но вполне прохладно относится к количеству ядер (процессоров) в системе. С другой стороны, рендеринг готовых сцен совершенно некритичен к видеосистеме — но очень критичен не только к скорости единичного процессора (ядра), но и к их количеству. Таким образом, мы сочли концептуально правильным разнести интерактивные и рендеринговые результаты трёхмерных пакетов по двум разным группам. Интерактивные баллы учитываются в данной группе: «3D-визуализация», а результаты тестирования скорости рендеринга мы выделили в отдельную группу: «Рендеринг трёмхерных сцен».
Однако в эту же визуализационную группу просятся не только результаты интерактивных тестов в пакетах трёхмерного моделирования, но и другие наши старые знакомые: CAD/CAM-пакеты SolidWorks, PTC Pro/ENGINEER и UGS NX. В их тестах также есть отдельно выделяемая в общем списке результатов графическая составляющая, и, по сути, она означает то же, что и интерактивные баллы в тестах трёхмерных пакетов: быстродействие программы, работающей с определёнными аппаратными средствами, при выводе трёхмерных изображений на экран в реальном масштабе времени с помощью какого-либо графического API (в нашем случае все три CAD-пакета используют OpenGL). Таким образом, данный раздел методики объединяет в себе 7 пакетов, 3 из которых относятся к ПО для трёхмерного моделирования, 3 — к инженерно-конструкторскому ПО, и ещё один представляет собой 10-е поколение знаменитого теста SPEC viewperf — также предназначенного для оценки быстродействия при визуализации трёхмерных объектов с помощью OpenGL в реальном масштабе времени. Остановимся более подробно на каждом тесте, так как они довольно сложные и разноплановые.
3ds max
Мы продолжаем с сожалением констатировать отсутствие теста SPECapc для актуальной на данный момент версии 3ds max, что вынуждает нас прибегать к всё большему количеству ухищрений, чтобы продолжать использовать с новой версией пакета бенчмарк, предназначенный для ещё для его «дедушки» (3ds max 9 — 3ds max 2008 — 3ds max 2009). Увы, равного по функционалу SPECapc for 3ds max 9 альтернативного бенчмарка для 3ds max, мы не знаем. Однако ситуация год от года ухудшается: если в комбинации с 3ds max 2008, бенчмарк от SPEC работал с некоторыми нюансами, но, по крайней мере, в полном объёме, то с 3ds max 2009 некоторые фрагменты тестового скрипта отказались работать вовсе. Программа на них либо просто падала, либо происходящее в основном окне безобразие совершенно очевидно свидетельствовало о том, что тест выполняет совсем не те операции, которые должен. В результате, нам пришлось исключить из тестирования часть сцен, используемых в оригинальном тесте от SPEC, и переработать в соответствии с этими исключениями итоговую таблицу оценки и формулы, по которым подсчитываются средние баллы (разумеется, сохраняя, по возможности, логику оригинала). Таким образом, в нынешнем виде результаты используемого нами теста в их числовом выражении уже гарантированно не будут иметь ничего общего с результатами оригинального теста от SPEC, и применимы только для сравнения между собой.
И уж коль мы были просто вынуждены замахнуться на святое, чтобы тест сохранил работоспособность, никто не мешал нам ещё чуть-чуть переработать бенчмарк SPEC с целью сделать его результаты более интересными. Мы решили осовременить секцию рендеринга. После нашей переделки, в модифицированной версии бенчмарка для рендеринга всех сцен используется не оригинальный (и подавляющему большинству профессионалов совершенно не интересный) встроенный рендер 3ds max Scanline, а достаточно популярный в профессиональной среде рендер V-Ray. Кроме того, мы усложнили сами сцены: вместо стандартных входящих в комплект теста (и достаточно лёгких для современных процессоров) сцен Throne Shadowmap, CBALLS2 и Space FlyBy, «подсунули» бенчмарку сцены 01, 02 и 07 из сборника Evermotion Archinteriors Vol 1. Разумеется, вряд ли нашими скромными стараниями нам удалось сделать аналог гипотетического SPECapc for 3ds max 2009 — однако, как говорится, «за неимением гербовой бумаги...»
Maya
C момента выхода SPECapc for Maya 6.5 прошло ещё больше времени, так что и этот бенчмарк нельзя назвать блещущим новизной. Однако, как мы уже писали в статье, посвящённой предыдущей версии методики, небольшая правка в одном файле сцены позволяет успешно использовать его даже с последними версиями Maya. В данном случае, тест от SPEC содержит только интерактивную составляющую, и не оценивает скорость рендеринга. Мы исправляем этот недостаток традиционным способом: с помощью замера времени рендеринга нашей собственной сцены для Maya (используется рендер MentalRay). Можно сказать, что в данном тесте по отношению к предыдущей версии методики ничего не изменилось, за исключением версии программного пакета.
Lightwave
Наконец, свершилось! SPEC выпустила тест для Lightwave, которого нам так не хватало все эти годы. Для самой последней (в том числе 64-битной) версии, и настоящий, по-спековски взрослый — с интерактивной частью, рендерингом, и даже оценкой скорости работы в многозадачном окружении. Разумеется, это намного более хорошее решение, чем используемый нами в предыдущих методиках единичный тест на скорость рендеринга сцены — и с точки зрения полноты охвата, и (не без того) — с точки зрения авторитетности разработчика бенчмарка. К сожалению, других комментариев, кроме нашей радости от данного события, мы дать не можем: тест новый, никакой статистики по нему ещё нет. Впрочем — формальным критериям отбора он удовлетворяет: современное ПО поддерживает, завершает выполнение штатным образом, результаты выводит — что ещё нужно для начала?
SolidWorks
Этот тест присутствует в нашей методике уже не первый год. Но, к сожалению, за все эти годы SPEC так и не выпустила ни одного обновления своего бенчмарка, поэтому с выходом каждой новой версии SolidWorks, мы, затаив дыхание, запускаем на ней в первый раз SPECaps for SolidWorks 2007... и облегчённо вздыхаем: опять повезло — работает. Сам бенчмарк, по сути, очень похож (даже внешне) на прочие тесты SPECapc — в том числе и для пакетов трёхмерного моделирования: он замеряет производительность в трёх аспектах — процессорозависимые операции, графика, операции ввода-вывода (де-факто речь идёт о скорости дисковой подсистемы). Результаты представляют собой количество секунд, которое было затрачено на выполнение соответствующих частей бенчмарка (соответственно, лучшим является меньший результат). Напомним, что в данном разделе участвует только один результат теста — «Graphics».
Pro/ENGINEER
Для Pro/ENGINEER мы используем OCUS Benchmark, так как этот тест развивается намного динамичнее SPECapc for Pro/ENGINEER — у него есть 64-битная версия, в которой задействуется большой объём ОЗУ (а это на практике оказалось одним из самых главных преимуществ 64-битных систем), бенчмарк поддерживает самую современную версию Pro/ENGINEER Wildfire. То есть нет ни одного повода использовать старый тест от SPEC. Несмотря на то, что OCUS Benchmark разрабатывается совершенно независимо, в нём также присутствуют три результата уже знакомого нам типа: «Graphics related tasks», «CPU related tasks» и «Disk related tasks». Как и в случае с предыдущим тестом, это сумма секунд, потраченных на выполнение заданий, относящихся к соответствующей группе. В разделе визуализации из всех баллов участвует только «Graphics related tasks».
UGS NX
Ещё один CAD/CAM пакет, и ещё один старый тест от SPEC — SPECapc for UGS NX 4 (в данной методике тестирования сам пакет представлен своей 6-й версией). К счастью, тест совершенно нормально работает с обновлённым пакетом. По сути, он как близнец похож на два предыдущих: три итоговых балла, один отвечает за производительность графики, второй за производительность процессора, третий — за производительность операций ввода-вывода. Нас в рамках данного раздела интересует, соответственно, первый — графический.
SPEC viewperf 10
Знаменитый тест с давней и славной историей. Предназначался он с самого момента своего создания для анализа исключительно визуализационной (графической) составляющей производительности, причём опять-таки традиционно в нём представлены только те пакеты, которые могут использовать OpenGL. Фактически, viewperf — это и есть самый общепризнанный инструмент для интегральной оценки производительности видеокарт при работе с ними через API OpenGL. В нашей методике он присутствует в качестве опции: если мы тестируем компьютерную систему с прицелом на оценку производительности CPU — в нём нет нужды, так как от CPU результаты viewperf практически не зависят. А если нам нужно сравнить комплексно две системы, в которых установлены разные видеокарты — тогда результат viewperf в разделе «3D-визуализация» может быть очень полезен. 10-я версия теста впервые с начала его существования поддерживает многопоточность. Впрочем, реализация этой поддержки пока достаточно примитивна: тест может исполняться в одно- двух- и четырёхпоточном варианте (другие, например, трёх- или 6-8-поточные — не предусмотрены), кроме того, многопоточность задействуется самым примитивным способом: просто запускается несколько копий теста (то есть мы наблюдаем на экране 2 или 4 одинаковых окна, в которых происходит одно и то же).
Технические подробности
- ПО: 3ds max 2009 x64 + SP1, V-Ray for 3ds max x64 1.50 SP2, SPECapc for 3ds max 9. Тестирование: после установки SPECapc for 3ds max 9, в каталог Program FilesAutodesk3ds Max 2009MAXTestScriptFiles записать скачанный у нас файл UIarrayAutomation.ms (если в каталоге уже есть такой файл — записать поверх). Перейти в каталог Program FilesAutodesk3ds Max 2009MAXTestScenes, заменить сцены throne_shadowmap, cballs2 и space_flyby на сцены 01, 02 и 07 из набора Evermotion Archinteriors Vol 1. Графические файлы, прилагающиеся к сценам Evermotion Archinteriors, скопировать в каталог Program FilesAutodesk3ds Max 2009maps. Запуск теста: MaxTestAuto.bat в каталоге Program FilesAutodesk3ds Max 2009. В этом разделе методики участвует балл «Graphics». Тест запускается 5 раз, результаты усредняются.
- ПО: Maya 2009 x64 + SP1, SPECapс for Maya 6.5. Тестирование: после установки SPECapс for Maya 6.5, заменить файл Program FilesSPECapcMayaBenchmarkInsectscenesInsect.ma на скачанный с нашего сайта. Далее запускать тест согласно инструкции. В этом разделе методики участвует балл «GFX». Тест запускается 5 раз, результаты усредняются.
- ПО: Lightwave 3D x64 9.6. SPECapc for Lightwave 3D 9.6. Инструкции по запуску теста прилагаются к SPECapc for Lightwave 3D 9.6, никаких изменений не требуется. В этом разделе методики участвует балл «Interactive», меньшее значение означает лучший результат. Тест запускается 5 раз, результаты усредняются.
- ПО: SolidWorks 2009 x64 SP0.0, SPECapc for SolidWorks 2007. Тестирование: согласно инструкции к SPECapc for SolidWorks 2007, появляющееся сообщение об ошибке игнорировать, нажимая OK. В этом разделе методики участвует балл «Graphics», меньшее значение означает лучший результат. По умолчанию тест сам предлагает 5 итераций, и сам усредняет результат.
- ПО: Pro/ENGINEER Wildfire x64 4.0 (M070), OCUS Benchmark v5.1. Тестирование: запускать 64-битную версию теста согласно инструкции. В этом разделе методики участвует балл «Graphics related tasks», меньшее значение означает лучший результат. Тест запускается 5 раз, результаты усредняются.
- ПО: UGS NX x64 6.0, SPECapc for UGS NX 4. Настройки: заменить файл Program FilesSPECapcNX4mark x4mark.bat на модифицированный. Тестирование: запускать тест согласно инструкции к SPECapc for UGS NX 4. В этом разделе методики участвует балл «Total Graphics». Тест запускается 5 раз, результаты усредняются.
- ПО: SPEC viewperf 10. Тестирование: запускается одно- двух- и четырёх- поточная версия теста, результирующим баллом для каждого подтеста является лучший из трех результатов. Тест запускается 5 раз, результаты усредняются. Общий балл теста вычисляется, как среднее геометрическое результатов всех подтестов.
Итоговый балл по группе вычисляется, как среднее геометрическое результатов всех тестов (в случае, когда меньшее значение означает лучший результат, в среднем, геометрическом результат участвует как 1/x).
Группа 2. Рендеринг трёхмерных сцен.
В этой подгруппе участвуют пакеты 3ds max, Maya и Lightwave с результатами рендеринга. Почему нам показалось целесообразным выделить скорость рендеринга трёхмерных сцен в отдельный раздел методики? Сама по себе эта задача относится к достаточно узкому и специфическому классу. Во-первых, это почти идеально распараллеливаемый процесс: прирост быстродействия при добавлении ещё одного ядра (процессора) в систему зачастую составляет цифру, приближающуюся к 100%. Таким образом, будет вполне логично сравнивать между собой процессоры с различным количеством ядер обособленно в рендеринге: с одной стороны, так виднее преимущество систем с большим количеством ядер, а с другой — результаты рендеринга не разбавляют собой производительность, например, в области визуализации (где количество ядер по-прежнему не очень сильно влияет на скорость). Во-вторых, отнюдь не для всех (даже работающих с пакетами трёхмерного моделирования) пользователей скорость рендеринга на их рабочих системах важна. Если речь идёт о крупной дизайнерской компании — то там для финального рендеринга сцен зачастую используются компьютеры, специально выделенные исключительно для этой задачи (а иногда и рендер-фермы из нескольких компьютеров). Если речь идёт о дизайнере, работающем индивидуально, — то он, как правило, довольно редко запускает процесс финального (не preview) рендеринга, и даже когда делает это — сам за компьютером в это время не работает (например, запускает процесс рендеринга на ночь, когда ложится спать). Нам показалось правильным обособить результаты тестирования на скорость рендеринга в отдельный раздел — чтобы те, кого действительно интересует данная задача, могли получить наиболее полную и не разбавленную другими результатами информацию, те же, кого скорость рендеринга, наоборот, совершенно не интересует — не были вынуждены вручную «выковыривать» не нужные им результаты из, в целом, интересного раздела.
Технические подробности
- ПО: 3ds max 2009 x64 + SP1, V-Ray for 3ds max x64 1.50 SP2, SPECapc for 3ds max 9. Тестирование: после установки SPECapc for 3ds max 2007, в каталог Program FilesAutodesk3ds Max 2009MAXTestScriptFiles записать скачанный у нас файл UIarrayAutomation.ms (если в каталоге уже есть такой файл — записать поверх). Перейти в каталог Program FilesAutodesk3ds Max 2009MAXTestScenes, заменить сцены throne_shadowmap, cballs2 и space_flyby на сцены 01, 02 и 07 из набора Evermotion Archinteriors Vol 1 (то есть сцены из набора Archinteriors должны быть помещены в каталог ...MAXTestScenes под именами соответствующих родных сцен теста). Графические файлы, прилагающиеся к сценам Evermotion Archinteriors, скопировать в каталог Program FilesAutodesk3ds Max 2009maps. Запуск теста: MaxTestAuto.bat в каталоге Program FilesAutodesk3ds Max 2009. В этом разделе методики участвует балл «Rendering». Тест запускается 5 раз, результаты усредняются.
- ПО: Maya 2009 x64 SP1, cцена для рендеринга. Результатом теста является время рендеринга сцены.
- ПО: Lightwave 3D x64 9.6. SPECapc for Lightwave 3D 9.6. Инструкции по запуску теста прилагаются к SPECapc for Lightwave 3D 9.6, никаких изменений не требуется. В этом разделе методики участвует балл «Rendering», меньшее значение означает лучший результат. Тест запускается 5 раз, результаты усредняются.
- Все установки пакетов и рендеров — по умолчанию после инсталляции.
Итоговый балл по группе вычисляется, как среднее геометрическое результатов всех тестов. В данном разделе результат теста 3ds max участвует в неизменном виде, все остальные — в виде 1/x.
Группа 3. Научные и инженерные расчёты.
В этом разделе аккумулируются результаты, относящиеся к всевозможным расчётам. Его прообразом был раздел, посвящённый научно-математическим пакетам (в предыдущей версии методики). В новой версии методики мы решили аккумулировать в одном разделе все результаты подобного плана. Действительно: понятно, что MAPLE, Mathematica, MATLAB — это инструменты для учёных и инженеров. Однако те же CAD/CAM-пакеты — SolidWorks, Pro/ENGINEER, UGS NX — тоже осуществляют инженерные вычисления, и в тестах для этих пакетов тоже существует обособленный вычислительный результат. При этом, несмотря на внешне видимые различия, суть остаётся той же: да, Pro/ENGINEER может красиво повертеть деталь или механизм на экране, однако перед этим он всё равно должен их просчитать. Таким образом, в этот раздел методики вошли как тесты для научно-математических пакетов, так и процессорные баллы бенчмарков SolidWorks, Pro/ENGINEER и UGS NX. Поскольку последние уже были описаны ранее, остановимся на математических пакетах.
Тест (точнее, два теста) для Mathematica остался таким же, как и в предыдущей версии методики, поменялась только версия самого пакета. Тест для MAPLE, в принципе, остался почти таким же, но в нём были подкорректированы в сторону увеличения некоторые параметры — размерности массивов, матриц, etc, в связи с чем возросли требования теста к памяти: если ранее он задействовал под данные порядка 4-6 МБ ОЗУ (что, как легко заметить, означает, что у некоторых процессоров все операции происходили, скорее всего, в L2-кэше), то теперь тест задействует порядка 40-45 МБ ОЗУ, что однозначно выходит за пределы кэширования любого известного нам x64-процессора (и, скорее всего, ещё долго будет выходить). Однако наиболее интересные изменения произошли с тестом MATLAB.
Пакет MATLAB имеет встроенный бенчмарк, и, казалось бы, — кто лучше разработчиков пакета знает, как тестировать его производительность? К сожалению, в данном случае это, видимо, не так (или они включили этот бенчмарк в состав пакета когда-то давно, и с тех пор не корректировали). По факту, встроенный в MATLAB 2008 бенчмарк демонстрирует очень нестабильную работу: даже если в процессе прохождения теста округлять результат 100 (!) итераций — всё равно разброс между соседними запусками может составлять до 20%! Фактически, встал вопрос о том, чтобы исключить MATLAB из списка тестируемых пакетов именно из-за неадекватности результатов тестов. К счастью, видимо, не мы одни столкнулись с неадекватностью встроенной функции тестирования быстродействия в MATLAB, и нам удалось найти достаточно интересную стороннюю разработку, которая теперь используется в тестах. Кстати, этот бенчмарк не только более стабилен и предсказуем, но и существенно подробнее в плане результатов.
Технические подробности
- ПО: Mathematica x64 7.01. Тесты: Internal.nb, MMA.nb. Запуск тестов (из командной строки): math.exe <путь и имя файла с тестом>. Каждый тест исполняется по 5 раз, результаты усредняются. Общий балл пакета — среднее геометрическое двух усреднённых результатов.
- ПО: MAPLE 12. Тест: SciGmark.txt. Запуск теста (из командной строки): cmaple.exe scigmark.txt. Тест исполняется 5 раз, результаты усредняются.
- ПО: MATLAB x64 r2008b (7.7). Тест: бенчмарк от SciViews.org. Тест исполняется 10 раз, результаты усредняются (количество итераций можно задать в самом бенчмарке, присвоив нужное значение переменной runs).
- ПО: Pro/ENGINEER Wildfire x64 4.0 (M070). Тест: OCUS Benchmark v5.1 (64-битная версия). В разделе участвует балл теста «CPU Related Tasks» (меньшее значение означает лучший результат). Тест исполняется 5 раз, результаты усредняются.
- ПО: SolidWorks x64 2009 SP0.0. Тест: SPECapc for SolidWorks 2007. В разделе участвует балл теста «CPU» (меньшее значение означает лучший результат). Тест исполняется 5 раз, результаты усредняются.
- ПО: UGS NX x64 6.0. Тест: SPECapc for UGS NX 4. В разделе участвует балл теста «Total CPU». Тест исполняется 5 раз, результаты усредняются.
- Настройки всех программных пакетов и тестов — по умолчанию после инсталляции.
Итоговый балл по группе вычисляется, как среднее геометрическое результатов всех тестов (в случае, когда меньшее значение означает лучший результат, в среднем геометрическом результат участвует как 1/x).
Группа 4. Растровая графика.
Раскроем маленький секрет: достаточно амбициозное название (вместо, например, работы с цифровой фотографией) данный раздел получил потому, что в недрах нашей тестовой лаборатории, в содружестве с привлечёнными со стороны специалистами, готовится ещё один раздел методики: «Векторная графика». К сожалению, процесс разработки бенчмарков ещё далёк от завершения, поэтому сегодняшняя версия методики пока не содержит в себе такого раздела. Но мы надеемся, что уже в следующей версии он обязательно будет. Однако вернёмся в настоящее.
Гегемония Adobe Photoshop на рынке программ для работы с растровой графикой — объективно существующий факт, и ранее, мы его принимали как данность. Лишь в прошлой версии методики впервые была предпринята робкая попытка чем-то разбавить единственный в группе тест (и то — путём создания параллельной по смыслу группы). Быть может, данная попытка была не очень методологически выдержана (3 вьювера и 1 оптимизатор дружно занимались выполнением одной и той же задачи по batch-конвертации файлов, а единственный альтернативный графический редактор был подобран нарочито простенький) — однако начало было положено. Сегодня в группе «Растровая графика» для тестирования производительности используется 3 полноценных графических пакета: разумеется, последняя версия Adobe Photoshop (куда же без него?), но кроме него ещё есть Corel PhotoImpact X3 (бывший Ulead PhotoImpact) и Corel PaintShop Pro Photo X2 (бывший Jasc PaintShop). Кроме того, мы по-прежнему используем для тестов простенький но зато очень компактный редактор Paint.NET (право слово, для большинства непрофессиональных задач вполне хватает и его функциональности), также остался в наборе бенчмарков и самый популярный графический вьювер — ACDSee. Впрочем, последний теперь выполняет более сложную задачу, чем раньше, — он конвертирует RAW-форматы в JPEG. В качестве объектов для конвертации выступают файлы формата NEF (Nicon) и CR2 (Canon), собранные в единый файловый набор размером около 1 ГБ, в примерно равном отношении.
Тест для Adobe Photoshop был переделан, в основном, в сторону увеличения нагрузки, то есть усложнения задач. Однако смысл его остался неизменным: тестовый скрипт засекает время выполнения над тестовым изображением действий (Actions), сгруппированных в подгруппы — Blur, Sharp, Light (световые эффекты), Resize, Rotate, Convert (преобразование из одной цветовой модели в другую), Transform и Filters. Каждая группа имеет равный вес в итоговом балле, однако и информация по отдельным группам тоже доступна. Тесты для Corel PhotoImpact X3 и PaintShop Pro Photo X2 разрабатывались нами по аналогичной схеме: сначала происходит загрузка тестового изображения, потом над ним выполняются действия, заскриптованные с помощью встроенного в соответствующее приложение языка, результатом теста является общее время выполнения этих действий (соответственно, чем оно меньше — тем лучше). Правда, в двух последних бенчмарках мы не стали разделять операции на какие-то группы, и фиксируем время выполнения всего скрипта целиком.
Технические подробности
- ПО: ACDSee Pro 2.5.363 (RAW Plugin 4.0.62). Настройки: файл для импорта в реестр. Тестирование: открыть папку с набором тестовых RAW-файлов*, произвести операции «Select All» — «Batch Convert File Format» (JPEG). Тестируется время конвертации. Тест выполняется 5 раз, результаты усредняются.
- ПО: Paint.NET x64 3.36, PdnBench 3.20. Инструкции по запуску прилагаются к бенчмарку. Тест выполняется 5 раз, результаты усредняются.
- ПО: Adobe Photoshop CS4 x64 (11.0.1). Настройки: установки окружения распаковать в каталог Users<имя пользователя>AppDataRoamingAdobeAdobe Photoshop CS4 (если в каталоге уже имеется некое содержимое — предварительно стереть его). Запустить Adobe Photoshop CS4 x64, подключить Actions для теста. Загрузить тестовое изображение. Нажатие функциональных клавиш с F2 по F9 запускает соответствующую группу тестов. Замерить время имполнения каждой группы 5 раз, результаты усреднить. Общий балл вычисляется, как среднее геометрическое результатов всех групп.
- ПО: Corel PhotoImpact X3. Настройки: установки окружения распаковать в каталог Users<имя пользователя>AppDataRoamingUlead Systems (если в каталоге уже есть подкаталог Ulead PhotoImpact — стереть его). Запустить Corel PhotoImpact X3, загрузить тестовое изображение. Из стандартной панели Quick Command, выполнить скрипт «iXBT PhotoImpact Test», засечь время его исполнения. Повторить 5 раз, результаты усреднить.
- ПО: Corel PaintShop Pro Photo X2. Настройки: файл для импорта в реестр, установки окружения (распаковать в каталог Users<имя пользователя>DocumentsMy PSP Files, предварительно очистив его в случае если содержимое уже имеется). Строка запуска теста: "Program Files (x86)CorelCorel Paint Shop Pro Photo X2Corel Paint Shop Pro Photo.exe" "Users<имя пользователя>DocumentsMy PSP FilesScripts-Trusted est.pspScript" "<имя тестового файла с полным путём к нему>". Засекается время выполнения тестового скрипта. Тест проводится 5 раз, результат усредняется.
* — ввиду большого размера набора, ссылка высылается по отдельному запросу.
Группа 5. Сжатие данных.
Тестирование скорости сжатия разнородных данных без потерь (этот процесс принято называть архивацией) является достаточно традиционным бенчмарком, также давно известно, какие параметры системы являются для подавляющего большинства архиваторов критичными: на первом месте располагается вычислительная мощность целочисленных функциональных устройств процессора, на втором — общий размер и быстродействие кэшей всех уровней, на третьем — производительность подсистемы памяти, причём критичны как скорости линейного чтения и записи, так и латентность. Реже (в последнее время практически никогда) сказывалась пропускная способность процессорной шины — впрочем, это относится к тем (ныне уже отходящим) временам, когда контроллер памяти располагался в чипсете.
Наш бенчмарк, традиционно, состоит в архивации с помощью каждого из используемых в тесте архиваторов одинакового файлового набора, состоящего из примерно равных объёмов файлов следующих типов: BMP (несжатая картинка), DBF (база данных), DLL (динамическая библиотека), DOC (документ Microsoft Word 97/2003), PDF (документ формата PDF) и TXT (простой текст в кодировке Win-1251). В нынешней методике, по отношению к предыдущим практически ничего не изменилось, разве что мы были вынуждены увеличить объём файлового набора, чтобы слишком малое время архивации не влияло на стабильность и повторяемость результатов. И, разумеется, обновились версии используемого ПО. Некоторые, к слову, обновились достаточно кардинальным образом: WinRAR впервые представлен в 64-битном качестве. К сожалению, 64-битный релиз на момент разработки методики ещё не был доступен, однако мы оценили стабильность бета-версии как достаточно высокую, и включили её в состав тестов. Опции архивации неизменны уже в течение многих лет: solid-архив, максимальная степень сжатия, количество потоков равно количеству процессорных ядер. Справедливости ради, в случае с 7-Zip указывать более двух потоков не имеет смысла, так как он не поддерживает разбиение процесса сжатия на большее их количество. Но мы всё равно честно указываем в опциях архиватора реальное количество ядер — так, на всякий случай.
У некоторых может возникнуть вопрос: а почему не используются бенчмарки, встроенные в сами приложения, — ведь они есть и в 7-Zip и в WinRAR? Ответ прост: к сожалению, на примере встроенного бенчмарка WinRAR мы убедились, что даже когда тест пишет сам автор программы, это вовсе не гарантирует реалистичность результатов. Так, встроенный тест WinRAR очень благосклонно реагирует на повышение количества ядер, вплоть до 4-х, однако… этого совершенно не наблюдается при выполнении тем же архиватором реальной работы по архивации файлов: прирост скорости, начиная с добавления третьего ядра, — существенно ниже, чем по показаниям бенчмарка. Судя по всему, бенчмарк имитирует работу программного ядра архиватора в ситуации, близкой к идеальной (по распараллеливаемости процессов) — отсюда и расхождение в оценках с реальностью. Поглядев на данную ситуацию со стороны, мы решили, что старый добрый способ тестирования с помощью архивации на время файлового набора — больше соответствует нашему основному принципу: предоставлять пользователям информацию о реальной производительности компьютерных комплектующих на примере решения с их помощью реальных пользовательских задач. А использовать в рамках группы из двух тестов два разных способа тестирования, было бы и вовсе нелепо, поэтому судьба встроенного теста 7-Zip определилась автоматически.
Технические подробности
- ПО: 7-Zip x64 4.65. Тестирование: архивация файлового набора*. Строка запуска: 7z.exe a -r -mx=9 -mmt<количество процессоров в системе> <имя архива> <путь к файловому набору>*.*. Тестируется время архивирования. Тест выполняется 5 раз, результаты усредняются.
- ПО: WinRAR x64 3.90 beta 3. Тестирование: архивация файлового набора*. Строка запуска: rar.exe a -r -m5 -s -mdg -mt<количество процессоров в системе> <имя архива> <путь к файловому набору>*.*. Тестируется время архивирования. Тест выполняется 5 раз, результаты усредняются.
Итоговый балл по группе вычисляется, как среднее геометрическое результатов всех тестов.
* — ввиду большого размера архива, ссылка высылается по отдельному запросу.
Группа 6. Компиляция (VC++).
Основные претензии к предыдущему тесту на скорость компиляции состояли в том, что он достаточно слабо распараллеливал данный процесс, в результате чего системы с большим количеством процессорных ядер не получали должного преимущества над системами с меньшим их количеством. Как оказалось (спасибо нашему читателю за помощь в диагностике проблем и поиске методов их решения), данную проблему можно было решить достаточно малой кровью: не меняя ни используемого компилятора, ни даже проекта — исключительно за счёт тонкого тюнинга самого проекта и опций компилятора. Соответственно, данный бенчмарк в рассматриваемой методике тестирования можно считать одновременно и старым, и новым. Старым — потому что не изменился ни компилятор (Microsoft Visual Studio 2008), ни проект (Ogre 3D — Open Source 3D Graphics Engine). Новым — потому что теперь бенчмарк совершенно по-другому себя ведёт, и намного более благосклонен к системам с большим количеством ядер.
Технические подробности
ПО: Microsoft Visual Studio 2008 (9.0.21022.8 RTM), Microsoft DirectX SDK (March 2009). Исходники для компиляции: модифицированный проект Ogre3D, Visual C++.Net 2008 (9.0) Precompiled Dependencies. Тестируется время компиляции всего проекта. Тест проводится 5 раз, результаты усредняются.
Группа 7. Java.
С нашей точки зрения, вполне логично включить эту новую группу в нашу методику тестирования — пусть она и состоит всего из одного бенчмарка, который тестирует скорость выполнения программ на одном конкретном языке. Разумеется, в дальнейшем мы, может быть, расширим данную группу (да и группу компиляции тоже можно бы расширить...), однако даже сейчас она вполне репрезентативна: с точки зрения выполнения на компьютерах конечных пользователей, Java действительно является самым распространённым из языков программирования, а её Windows-реализация от Sun Microsystems — самой распространённой реализацией JRE (Java Runtime Environment). Что касается самого теста, то мы в который раз воспользовались бенчмарком от SPEC — SPECjvm2008. Он достаточно подробен, и включает в себя много подтестов из самых разных областей: Compiler (компиляция с помощью OpenJDK), Compress (сжатие данных по методу LZW), Crypto (шифрование по протоколам AES/DES, RSA, верификация по методам MD5withRSA, SHA1withRSA, SHA1withDSA и SHA256withRSA), Derby (тест использует open source БД, целиком написанную на Java), MPEGAudio (декодирование mp3 на базе LGPL-библиотеки JLayer), Scimark (популярный в научной среде бенчмарк вычислений с плавающей точкой, кстати, — мы используем его адаптированную под MAPLE версию в соответствующем тесте), Serial (параллельно-последовательное преобразование), Sunflow (визуализация с помощью многопоточно-оптимизированного движка рендеринга с поддержкой global illumination), XML (наложение таблиц стилей на XML-документы и валидация XML-документов по схеме (xsd). Бенчмарк имеет частичную многопоточную оптимизацию (она присутствует, но не во всех тестах).
Технические подробности
ПО: SPECjvm2008, Sun JRE 6.13 for Windows x64. Инструкции по запуску прилагаются к бенчмарку. Дополнительные опции запуска: «-i 5» (5 итераций). Усреднение результатов производится самим бенчмарком.
Группа 8. Кодирование аудио.
В этот раз мы решили проблему практически полного отсутствия среди аудиокодеков многопоточно-оптимизированного программного обеспечения с помощью использования внешней оболочки — dBpoweramp, которая умеет запускать несколько процессов кодирования одновременно, делая, таким образом, процесс кодирования многопоточным, даже при использовании однопоточных кодеков. Дополнительным плюсом dBpoweramp является то, что у программы имеется собственный бенчмарк, выдающий в качестве результата соотношение между скоростью кодирования аудиопотока и скоростью его проигрывания (то есть, например, результат в 20 баллов означает, что аудиопоток длительностью 20 минут был закодирован за 1 минуту). Мы провели экспресс-исследование данного бенчмарка на адекватность (сопоставили результаты нескольких разных процессоров, согласно бенчмарка, и просто когда засекали время кодирования набора WAV-файлов с помощью dBpoweramp Music Converter), и убедились в том, что встроенный бенчмарк ведёт себя адекватно реальной ситуации, стабильно и предсказуемо. К сожалению, два кодека — Musepack и Windows Media Audio, нам пришлось исключить из списка, так как бенчмарк dBpoweramp некорректно с ними работает. Однако список кодеков всё равно получился более чем представительный: MP3 (LAME), Apple Lossless, FLAC, Nero AAC, Monkeys Audio и OGG Vorbis.
Технические подробности
ПО: dBpoweramp R13.1, dBpoweramp Bench Mark Tester. Каждый тест выполняется 5 раз, отдельно для каждого кодека. После этого результаты различных тестирований одного и того же кодека усредняются между собой, а общий балл по группе вычисляется, как среднее геометрическое результатов всех кодеков.
Группа 9. Кодирование видео.
Достаточно традиционный для наших методик раздел, который от версии к версии развивается, скорее, эволюционно, чем революционно. Впрочем, в новой методике добавился ещё один формат, чего не было достаточно давно. Итак, в здесь мы тестируем скорость перекодирования некоего файла с видеоданными из одного формата в другой. Из какого в какой? И с помощью чего?
- Файл формата AVI (DV), представляющий собой сборку из фрагментов любительской съёмки на цифровую видеокамеру, конвертируется в формат MPEG2 (DVD) с помощью программы Canopus ProCoder. Это классическая задача для многих пользователей, предпочитающих переносить снятые ими фрагменты на DVD.
- Файл формата MPEG2 (1920x1080, 5-минутный фрагмент фильма «Iron Man») — в форматы, которые любители рипов наиболее часто предпочитают использовать в своих видеотеках: DivX, XviD, x264, VC-1.
Таким образом, наши тесты охватывают как любителей оцифровки собственноручно снятых видеоматериалов, так и собирателей домашних медиатек, предпочитающих изготавливать рипы самостоятельно.
Технические подробности
- ПО: Grass Valley ProCoder 3.0.5. Исходник: файл формата DV (637 МБ). Опции и настройки: проект для ProCoder (пути к файлам в проекте можно скорректировать, отредактировав проект в любом текстовом редакторе, включая Notepad). Тестируется время кодирования. Тест выполняется 5 раз, результаты усредняются.
- ПО: DivX Pro 7.0, VirtualDub x86 1.8.8, AVISynth 2.5.8, AC3Filter 1.51a. Исходник: 5-минутный фрагмент из фильма «Iron Man» (с 00:02:00 по 00: 07:00), закодированный в формат MPEG2 с разрешением 1920x1080 и average bitrate 6000 (для уменьшения размера файла)*. Опции и настройки: проект для VirtualDub. Тестируется время кодирования. Тест выполняется 5 раз, результаты усредняются.
- ПО: XviD 1.2.1 Final Release, VirtualDub x86 1.8.8, AVISynth 2.5.8, AC3Filter 1.51a. Исходник: аналогично предыдущему тесту. Опции и настройки: проект для VirtualDub. Тестируется время кодирования. Тест выполняется 5 раз, результаты усредняются.
- ПО: x264 x86 r1163, AVISynth 2.5.8, AC3Filter 1.51a. Исходник: аналогично предыдущему тесту. Опции и настройки (строка запуска): x264.exe --crf 24.0 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --weightb --direct auto --subme 6 --trellis 1 --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate --progress -o temp.avi file.avs. Тестируется время кодирования. Тест выполняется 5 раз, результаты усредняются.
- ПО: Mainconcept Reference 1.6. Исходник: аналогично предыдущему тесту. Опции и настройки: проект для Mainconcept Reference (пути к файлам можно скорректировать вручную, открыв проект в Notepad). Тестируется время кодирования. Тест выполняется 5 раз, результаты усредняются.
* — Выложить этот фрагмент мы не можем, так как это будет нарушением закона, поэтому максимально точно описали, каким образом его можно изготовить самостоятельно.
Итоговый балл по группе вычисляется, как среднее геометрическое результатов всех тестов.
Группа 10. Проигрывание видео высокой чёткости.
Потенциальной аудиторией данной группы являются все, кто занимается просмотром видео высокой чёткости на персональном компьютере. Тест нашей собственной разработки позволяет выявить, насколько пригодна используемая аппаратная конфигурация для проигрывания HD-контента (качественная оценка: пригоден/не пригоден), и насколько сложной будет являться для неё эта задача (количественная оценка). Тест анализирует нагрузку на процессор при проигрывании одного из самых популярных HD-форматов: H.264. К сожалению, у используемого нами для тестирования плеера MPC HC x64 есть некоторые проблемы с поддержкой DXVA на другом распространённом формате — VC-1, поэтому от тестирования с помощью данного формата мы были вынуждены отказаться на этапе разработки бенчмарка.
Суть теста в том, что при помощи программного плеера Media Player Classic Homecinema проигрывается 10-минутный ролик с видео высокой чёткости, и в это время с помощью Riva Tuner 5 раз в секунду производится мониторинг параметра CPU usage (всех имеющихся ядер). Media Player Classic настроен на использование рендера EVR, что, по общему мнению, является наилучшим вариантом при работе данного плеера под управлением Microsoft Windows Vista. Плеер запускается развёрнутым на весь экран (maximize), но в оконном (не fullscreen) режиме, из дополнительной информации на экране включено только отображение статистики проигрывания. Проигрывание производится в двух различных ситуациях:
- Ролик формата H.264, аппаратное ускорение с применением GPU (DXVA) отключено;
- Ролик формата H.264, аппаратное ускорение с применением GPU (DXVA) включено.
Для каждого проигрывания, по результатам анализа лог-файлов Riva Tuner, вычисляются следующие результаты:
- Средняя нагрузка на процессор за время прохождения теста. Этот параметр соответствует усреднению тех значений, которые можно увидеть на соответствующей закладке Windows Task Manager.
- Минимальная и максимальная нагрузка, когда-либо наблюдавшаяся за время проведения теста.
- Также в конце каждого проигрывания снимается скриншот содержимого окна Media Player Classic, на котором видна статистика проигрывания. В данном случае нас интересует значение статистического параметра dropped frames (пропущенные кадры), причём в большинстве случаев как качественный показатель — оно равно нулю (пропущенных кадров не было, вердикт — система пригодна), или отличается от нуля (пропуск кадров имел место, вердикт -система не пригодна).
Осталось только добавить, что данный тест, как и SPEC viewperf 10, ещё не прописался в какой-либо группе на постоянной основе, то есть его результаты доступны в таблице, но ни на один общий групповой балл они не влияют. К слову, присутствие такого рода тестов — это ещё одно нововведение, которое мы опробуем впервые. Наличие подобных опциональных тестов в методике, с нашей точки зрения, делает её более гибкой. Поскольку результаты опциональных тестов не влияют ни на какие общие баллы, их можно добавлять в методику и удалять из неё в любой момент. С другой стороны, результаты этих тестов можно исследовать, обсуждать, накапливать статистику и отзывы читателей, что несколько динамизирует обстановку после замораживания методики на очередные год-полтора.
Технические подробности
ПО: Media Player Classic Home Cinema x64 1.2.908.0, RivaTuner 2.24. Условия тестирования: RivaTuner настраивается для мониторинга загрузки всех процессорных ядер с частотой 5 раз в секунду, с ведением лог-файла. Запускается Media Player Classic Homecinema, в нём запускается на проигрывание закодированный в формат H.264 ролик из фильма «Iron Man» (битрейт 30000, длительность 10 минут)*. После лог-файл анализируется: сначала вычисляются мгновенные показатели загрузки CPU путём суммирования загрузки по всем ядрам и деления на количество ядер, потом вычисляется минимальная, средняя и максимальная загрузка CPU за всё время прохождения теста. Установки для первого запуска (Software Mode): файл для импорта в реестр. Установки для второго запуска: (DXVA Mode): файл для импорта в реестр.
* — Выложить этот фрагмент мы не можем, так как это будет нарушением закона, поэтому описали, каким образом его можно изготовить самостоятельно.
Группа 11. Игровое 3D.
Игровой раздел традиционен для нашей методики, однако и здесь (пожалуй, впервые) произошли существенные изменения: теперь раздел делится на две большие части, каждая из которых ориентирована на различные компьютерные системы. Первая часть тестов достаточно традиционна и предназначена для исследования производительности относительно высокопроизводительных систем, оснащённых дискретной видеокартой. В этой подгруппе используются современные игры с высокими настройками качества и разрешения (1280x1024). В данной подгруппе мы окончательно отказались от некогда популярной идеи пытаться исследовать производительность процессора в играх путём выставления низкого разрешения и использования опций низкого качества (low quality) графики. С нашей точки зрения, подобные манипуляции приводят к выхолащиванию результатов, которые становятся уже полностью синтетическими, и перестают иметь отношение к реальности: ведь использование LQ-опций приводит, в том числе, к упрощению (или даже исключению) расчётов, возлагаемых на процессор, — таким образом, даже в рамках одного игрового engine, нагрузка на CPU в LQ и HQ-режимах может быть попросту разной, по сути, и набору выполняемых расчётов.
Вторая часть представлена достаточно старыми играми (примерно 3-4-летней давности) со средними настройками качества и в достаточно низком разрешении (800x600). Эта подгруппа, по нашему замыслу, позволит нам создать более полное представление об игровой производительности систем, оснащённых встроенной графикой. Действительно: некоторые встраиваемые решения до сих пор не имеют поддержки DirectX 10, а уж о скорости, в случае использования тестов из первой подгруппы, и вовсе говорить не приходится: какая разница, 3 или 4 fps продемонстрирует такая система в бенчмарке, например, Crysis Warhead? Ведь что 3, что 4 fps — это совершенно одинаково неиграбельно, несмотря на то, что в последнем случае мы имеем право говорить о формально наличествующем 33% преимуществе. Таким образом, данную подгруппу можно условно назвать игровыми тестами для слабеньких систем. Ни для кого не секрет, что именно таким образом их владельцы, любящие поиграть, как правило, и поступают: устанавливают хиты прошлых лет, и используют графические опции попроще.
Технические подробности
Первая подгруппа: игровые тесты для систем с дискретной графикой.
- Crysis WARHEAD (патч 1.1). Используется внешний бенчмарк от FRAMEBUFFER. Файл с настройками Benchmark Tool открывается из приложения. Файл с настройками игры записывается в папку Users<имя пользователя>DocumentsMy GamesCrysis_WARHEAD. Тест выполняется 5 раз, результаты усредняются.
- Devil May Cry 4. Используется бенчмарк, встроенный в игру (выдаёт 4 результата, для получения итогового они усредняются). Файл с настройками игры записывается в папку Users<имя пользователя>AppDataLocalCAPCOMDEVILMAYCRY4. Тест выполняется 1 раз, так как стабильность результатов очень высокая.
- Far Cry 2 (патч 1.01). Используется бенчмарк, встроенный в игру. Все установки задаются с помощью командной строки. Тест выполняется 5 раз, результаты усредняются.
- Grand Theft Auto IV (патч 1.2.1). Используется бенчмарк, встроенный в игру. Файлы с настройками игры (1, 2, 3) записываются в папку Users<имя пользователя>AppDataLocalRockstar GamesGTA IVSettings. Тест выполняется 5 раз, результаты усредняются.
- Left 4 Dead. Используется записанный фрагмент игры от Guru3D (инструкция прилагается). Файл с настройками игры записывается в папку <папка с установленной игрой>left4deadcfg. Игра запускается с опцией -dev, после чего вызывается консоль (~), и выполняется команда timedemo guru3d.dem. Тест выполняется 5 раз, результаты усредняются.
- Lost Planet: Extreme Condition DX10 Demo. Используется бенчмарк, встроенный в игру. Файл с настройками игры записывается в каталог Users<имя пользователя>AppDataLocalCAPCOMlostplanetTrial. Бенчмарк непрерывный и не имеет конца, поэтому его выполнение прерывается после 15 минут проигрывания. Результаты снимаются с экрана.
- S.T.A.L.K.E.R.: Clear Sky. DirectX 10 бенчмарк от разработчиков. Файл с установками теста импортируется в реестр. Промежуточный итог вычисляется, как среднее арифметическое результатов daybenchmark, nightbenchmark, rainbenchmark и sunshaftbenchmark. Тест выполняется 5 раз, итоговый результат вычисляется, как среднее арифметическое 5 промежуточных.
- Unreal Tournament 3 (патч 4) + Titan Pack. Используется встроенный бенчмарк (имитация сетевой игры, когда всеми игроками управляет компьютер) на карте CTF-FacingWorlds с 8-ю игроками на протяжении 20 минут. Файлы с настройками: первый распаковывается в каталог Users<имя пользователя>DocumentsMy GamesUnreal Tournament 3UTGameConfig, второй — в каталог Program Files (x86)Unreal Tournament 3UTGameConfig, третий — в каталог Program Files (x86)Unreal Tournament 3EngineConfig.
- World in Conflict (патч 1.010). Используется бенчмарк, встроенный в игру. Файл с настройками игры записывается в папку Users<имя пользователя>DocumentsWorld in Conflict. Тест выполняется 5 раз, результаты усредняются.
Вторая подгруппа: игровые тесты для систем с интегрированной графикой.
- Call of Duty 2 (патч 1.3). Используется записанный фрагмент игры от techPowerUp.com (инструкции по тестированию прилагаются). Файл с настройками игры записывается в каталог Program Files (x86)Call of Duty 2mainplayers<имя пользователя в игре>. Тест выполняется 5 раз, результаты усредняются.
- DOOM 3 (патч 1.3.1). Используется встроенный бенчмарк (demo1). Файл с настройками игры записывается в каталог Program Files (x86)DOOM 3ase. Строка запуска выглядит следующим образом: doom3.exe +set logfile 1 +set com_showFPS +set timescale 7 +set r_mode 4 +playdemo demo1 +wait 500 +playdemo demo1 +wait 500 +playdemo demo1 +wait 500 +timedemoquit demo1. Тест выполняется 5 раз, результаты усредняются.
- Far Cry (патч 1.4). Используется встроенный бенчмарк (уровень Training). Файл с настройками игры записывается в каталог Program Files (x86)Far Cry. Строка запуска выглядит следующим образом: FarCry.exe -DEVMODE "#demo_num_runs=3" "#demo_quit=1" "#r_Width=800" "#r_Height=600" "#s_DummySound=1" "map training" "demo training"'. Тест выполняется 5 раз, в качестве промежуточного результата используется наибольший, результаты усредняются.
- Serious Sam 2 (патч 2.070). Используется встроенный бенчмарк (Demo_0001). Файл с настройкам игры записывается в каталог Program Files (x86)Serious Sam 2ContentSeriousSam2. Строка запуска выглядит следующим образом: Sam2.exe +demo contentserioussam2demosDemo_0001.dem +bmk_bAutoQuit 1 +bmk_bBenchmarkDemos 1 +sam_demo 1 +sam_bBootSequence 0 +fullscreen 1 +width 800 +height 600. Тест выполняется 5 раз, результаты усредняются.
- S.T.A.L.K.E.R.: Shadow of Chernobyl (патч 1.6). Используется бенчмарк (flyby) buildings_timedemo (инструкции прилагаются). Файл с установками игры записывается в каталог UsersPublicDocumentsSTALKER-SHOC. Тест выполняется 5 раз, результаты усредняются.
- Unreal Tournament 2004 (патч 3369). Используется встроенный бенчмарк. Файл с настройками игры записывается в каталог System проинсталлированной игры. Строка запуска выглядит следующим образом: UT2004.exe BR-Colossus.ut2?spectatoronly=1?attractcam=1?quickstart=1?numbots=8 -benchmark -nosound -seconds=900 -800x600. Тест выполняется 5 раз, результаты усредняются.
Итоговый балл по группе вычисляется, как среднее геометрическое результатов всех тестов:
- при тестировании систем с дискретной графикой — первой подгруппы;
- при тестировании систем с интегрированной графикой — второй подгруппы.
Представленная вам методика тестирования производительности компьютерных систем — разумеется, в значительной степени является эволюционным продуктом. Она базируется на предыдущей версии, позиционируемой как методика тестирования скорости исключительно процессоров — и это легко можно обнаружить как по списку используемых бенчмарков, так и по большому количеству совпадений в наименованиях групп (разделов) тестов. Однако не стоит относиться к ней, как к совсем уж переходному продукту — на самом деле, в данной версии методики мы обозначили уже давно сформировавшуюся тенденцию: современного конечного пользователя компьютера интересует не столько производительность отдельных компонентов его системы, сколько быстродействие конечного решения с точки зрения наиболее часто возникающих задач.
С этой точки зрения, данная методика является, с одной стороны, практически законченно-совершенным вариантом старого, классического подхода, вобравшим в себя лучшие его черты (объёмность, всеохватность, традиционность). И, с другой стороны, — попыткой в рамках старого подхода реализовать максимум признаков нового: ориентированность на конкретные задачи, отход от отдельного тестирования производительности подсистем современного персонального компьютера в отрыве друг от друга в пользу комплексного подхода, и, в конечном итоге, — переход от тестирования скорости отдельных компонентов к тестированию быстродействия конечных пользовательских решений.
Тем не менее, разумеется, мы постарались удовлетворить и чаяния поклонников классического подхода к тестированию производительности процессоров. Надеемся, что нам это удалось, и желающие получить максимум информации в привычном им виде — её получат.
