Цели и задачи
Любое осмысленное действие должно приносить какую-то пользу, и тестирование в том числе. Однако само понятие «пользы» можно трактовать очень широко, поэтому прежде чем приступать к разработке методики тестирования, отнюдь нелишне более чётко представить себе цели, которых планируется достичь. Одни при подборе бенчмарков руководствуются личными предпочтениями (вполне вероятно, связанными со спецификой собственной работы или увлечений), другие — популярностью различных тестов среди прочих пользователей, третьи пишут низкоуровневые тесты на С++ или даже ассемблере сами (таких исследователей, как правило, интересует «микроархитектурная» производительность различных устройств, на уровне составляющих их блоков). Кого-то интересует скорость процессора, а кого-то — видеокарты. Часть тестировщиков считает своим долгом включать в список используемых бенчмарков только самые современные, хорошо оптимизированные программы, а другая — наоборот, продолжают использовать для тестов относительно старое, зато хорошо проверенное ПО. В любом случае, каждый, наверное, представляет, какую же информацию он желает получить от тестов. Задавались таким вопросом в своё время и мы, и ответом на него, надеемся, является и нынешняя, уже 5-я версия нашей единой методики тестирования. Что же интересует нас?
Нас более всего интересует реальная, практическая деятельность, осуществляемая разными людьми с помощью компьютеров. Синтетические и микроархитектурные тесты в своём роде тоже хороши, и разбирающемуся в предмете человеку их результаты могут сказать очень много, но нас их результаты не интересуют по одной простой причине: никакой полезной работы ни один синтетический бенчмарк по определению не производит. Поэтому все наши тесты — это тесты на основе реального ПО, которое используется людьми (чья профессия, кстати, совершенно не обязательно связана с IT) для некой осмысленной деятельности — будь то ретуширование свадебных фото, проектирование двигателя внутреннего сгорания, или даже составление домашней медиатеки (ведь работа для себя всё равно остаётся работой). На тех же основополагающих принципах основан и подбор программ, используемых для тестирования: полезность и распространённость. Бесполезная программа не имеет шансов попасть в нашу методику. Малораспространённая — тоже, потому что скорость работы этой программы мало кого сможет заинтересовать.
Разумеется, озвученный выше подход вряд ли может удовлетворить абсолютно всех. Поэтому мы не ставим перед собой такой задачи — мы выбрали, как нам кажется, достаточно многочисленную группу читателей, и стремимся наиболее полно соответствовать именно их потребностям. Потребностям других групп наверняка соответствует кто-нибудь другой.
Группировка и подсчёт результатов
Приложения в нашей методике тестирования объединяются в группы по признакам сходства выполняемых ими задач. При этом в статье публикуются только диаграммы с общими баллами по группам, а подробные результаты по каждому тесту выкладываются в виде отдельной таблицы, на которую даётся ссылка. Причина такого подхода очевидна: результатов очень много — так, например, тестирование по методике 2011 года, описанию которой посвящён этот материал, даёт 62 результата. Баллы производительности вычисляются следующим образом: сначала в баллы преобразуется результат каждого теста, исходя из производительности референсной системы, которая принимается равной 100 баллам. Потом выводится средний балл по группе, представляющий собой среднее арифметическое баллов производительности всех тестов, входящих в группу. Ну и наконец, вычисляется средний общий балл производительности тестируемой системы, который представляет собой среднее арифметическое баллов всех групп. Для методики 2011 года в качестве референсной используется система следующей конфигурации:
| Процессор | AMD Athlon II X4 620 |
| Системная плата | ASUS M4A78T-E |
| Память | 4×2=8 ГБ DDR3-1333 |
| Жёсткий диск | Intel SSD SA2M160G2GC 160 ГБ |
| Видеокарта | NVIDIA GeForce GTX 570 1280 МБ |
| Блок питания | Cooler Master RS-A00-EMBA 1000 Вт |
Постоянная составляющая
При любых тестированиях в рамках методики версии 5.0, постоянными остаются следующие программные компоненты:
- Microsoft Windows 7 Ultimate x64 SP1;
- NVIDIA ForceWare 270.61;
- NVIDIA PhysX System Software 9.10.0514;
- AMD Catalyst 11.3.
Также, если речь идёт о применении методики для тестирования производительности процессоров, постоянными остаются следующие аппаратные компоненты:
- Монитор с разрешением 1680×1050×32@60 Гц (22″);
- Видеокарта NVIDIA GeForce GTX 570 (1280 МБ);
- Блок питания Cooler Master Real Power M1000 (1000 Вт);
- Жёсткий диск Intel SSDSA2M160G2GC (160 ГБ);
- Системы с 2 и более каналами контроллера памяти, оснащаются ОЗУ в расчёте один модуль памяти 4 ГБ нужного типа на каждый канал;
- Системы с одноканальными контроллерами памяти оснащаются 2 модулями по 4 ГБ памяти нужного типа (итого 8 ГБ).
Основная группа
Основная группа и подгруппы, в неё входящие, обеспечивают достижение главной цели методики тестирования: подробное исследование производительности тестируемой системы с помощью основных наборов бенчмарков и выведение среднего балла, который в рамках рассматриваемой методики является универсальной обобщённой характеристикой производительности. Все группы тестов и отдельные бенчмарки, входящие в основную группу, влияют на формирование среднего балла и баллов групп на равных правах.
Интерактивная работа в трёхмерных пакетах
Ранее мы использовали в названии данной группы тестов слово «визуализация», но оно вызывало ненужные параллели с «рендерингом», поэтому группу было решено назвать более корректно. Суть действий, скорость выполнения которых оценивается в группе, достаточно проста: мы берём некое программное обеспечение, предназначенное для работы с трёхмерными объектами (это может быть пакет трёхмерного моделирования или инженерный CAD), и с помощью выполнения некоего скрипта пытаемся сымитировать действия пользователя при работе с этим ПО — перемещение объектов, их вращение, приближение и отдаление, создание модели, предварительный просмотр анимации и так далее. Например, если речь идёт о пакете трёхмерного моделирования, то описать список действий проще простого: всё остальное, кроме финального рендеринга. Из описания вполне очевидно, что тесты в группе достаточно сильно завязаны на быстродействие не только процессора, но и видеокарты, т. к. все используемые в методике трёхмерные пакеты умеют задействовать для ускорения вывода изображения на экран ресурсы GPU.
К сожалению, по сравнению с методикой 2010 года в группе наблюдаются потери: нам пришлось исключить интерактивные тесты SPEC для программ трёхмерного моделирования 3ds max и Lightwave 3D и инженерного CAD UGS NX. Причина проста, и для каждого случая одна и та же: тесты SPEC разрабатывались под старые версии упомянутого ПО, и с новыми версиями работать отказываются. Наши постоянные читатели, быть может, помнят, сколько лет мы «тянули» тест SPECapc for 3ds max 9, дорабатывая его под каждую новую версию продукта (3ds max 9 вышла в 2006 году)… увы, но для успешной работы этого бенчмарка под управлением 3ds max 2012 его пришлось бы «урезать» настолько, что использование оставшегося просто теряло смысл. Что касается адаптации к новым версиям ПО бенчмарков SPEC для Lightwave 3D и UGS NX, то мы предприняли некоторое количество попыток сделать это, но потом отказались: стало очевидно, что времени на эту задачу мы потратим очень много, а вот что было совершенно неочевидно — будет ли в конце положительный результат.
Однако осталось не так уж мало: пакет трёхмерного моделирования Autodesk Maya 2011 и инженерные CAD SolidWorks 2011 и Creo Elements/Pro 5.0 (новое название хорошо знакомого вам по предыдущим методикам пакета Pro/ENGINEER Wildfire). По предыдущим версиям методики мы знаем, что бенчмарки этой группы практически не умеют использовать несколько процессорных ядер, но достаточно сильно (примерно в равной степени) зависят от вычислительной производительности одиночного ядра и видеокарты.
Используемое ПО:
- Autodesk Maya 2011 x64 SP1
- SPECapc for Maya 2009
- PTC Creo Elements/Pro 5.0 x64
- OCUS Benchmark v5.1
- SolidWorks 2011 x64 SP2
- SPECapc for SolidWorks 2007
Финальный рендеринг трёхмерных сцен
Традиционная для нашей методики группа тестов, в которой производительность системы оценивается по времени финального рендеринга сцен в различных популярных пакетах трёхмерного моделирования. В этой версии методики мы используем три таких пакета: Autodesk 3ds max 2011 с дополнительно установленным рендером V-Ray, а также Autodesk Maya 2011 и NewTek Lightwave 3D 10 с их «родными» рендер-движками. Все пакеты представлены в методике тестирования своими 64-битными версиями.
Для комбинации 3ds max + V-Ray используется сцена «VRay_Test_neoVISUAL_v5». Данная сцена является в некотором роде «референсной» для оценки скорости рендеринга в среде профессионалов, использующих в работе 3ds max в комбинации с рендером V-Ray. Мы опробовали её, и пришли к выводу, что нашим требованиям она тоже вполне соответствует. Сцена для рендеринга в Autodesk Maya 2011 нами уже на протяжении многих лет используется собственная, созданная специально для наших тестов, лишь время от времени подвергающаяся экстенсивному «усложнению» с целью увеличения времени рендеринга на современных мощных процессорах. В методике 2011 года используется тот же вариант сцены, что и в предыдущей. Сцена для рендеринга в Lightwave 3D 10 — это модифицированная нами (опять-таки, с целью усложнения задачи) сцена «Alien Emissary» из раздаваемого бесплатно на сайте NewTek Lightwave Creature Kit.
Традиционно, тесты на скорость рендеринга благоволят процессорам с большим количеством ядер, т. к. все используемые нами рендер-движки умеют задействовать многоядерность с эфективностью, близкой к 100%. Ко всем остальным ТТХ компьютерных систем, не относящимся непосредственно к процессору (скорость работы с памятью, быстродействие жёсткого диска, производительность GPU), данная группа тестов практически равнодушна.
Используемое ПО:
- Autodesk 3ds max 2011 x64 SP1
- VRay 2.00.02 for 3ds max 2011 x64
- Autodesk Maya 2011 x64 SP1
- Lightwave 10 x64
Упаковка и распаковка
Архивация файлов — достаточно старая группа тестов, присутствовавшая ещё в самой первой версии унифицированной методики тестирования. Традиционно, для тестирования мы используем два архиватора — коммерческий WinRAR и бесплатный 7-Zip, в комбинации с нашим референсным набором для упаковки, который содержит примерно в равном соотношении файлы следующих типов: BMP (несжатая картинка), DBF (база данных), DLL (динамическая библиотека), DOC (документ Microsoft Word 97/2003), PDF (документ формата PDF) и TXT (простой текст в кодировке Win-1251). Суммарный размер файлового набора — порядка 900 МБ, достигаемая степень сжатия (для архива 7-Zip) — порядка 10%. Тестируется скорость упаковки архива, шифруемого с помощью 21-символьного пароля по алгоритму AES-256 (7-Zip) и AES-128 (WinRAR), а также скорость распаковки только что созданного архива — итого, группа содержит 4 теста.
Традиционно, данная группа тестов демонстрирует высокую (относительно других разделов методики) зависимость результатов от скорости работы с оперативной памятью. А вот чувствительность среднего балла по группе к количеству ядер процессора, скорее всего, в методике 2011 года снизится, т. к. грамотно использовать более двух ядер умеет только 7-Zip, и только при упаковке, распаковка же у обоих архиваторов является процессом сугубо одноядерным. Однако в нашу задачу отнюдь не входило создание идеальных условий для выигрыша многоядерных систем. Намного более интересно, как нам кажется, воссоздавать условия, близкие к реальности — в которой с процессом распаковки архива рядовому пользователю приходится встречаться даже чаще, чем с упаковкой.
Используемое ПО:
- 7-Zip 9.20 x64
- WinRAR 4.0 x64
Кодирование аудио
Ещё одна старая группа тестов, которую, в отличие от предыдущих, из каждой новой версии методики появляется искушение исключить: уж больно предсказуемы результаты. Впрочем, появление в последнее время достаточно большого количества устройств, оснащённых процессорами с экстремально низкой по нынешним меркам производительностью — нетбуков и неттопов, вроде бы снова сделало данный раздел методики более-менее актуальным и жизненным.
Как и в прошлом году, мы используем для кодирования внешнюю оболочку — dBpoweramp, которая умеет запускать столько одновременных процессов кодирования, сколько процессорных ядер она обнаружит в системе. Список форматов звуковых файлов также остался неизменным: Apple lossless, FLAC, Monkey’s Audio, MP3 (кодек LAME), Nero AAC, Ogg Vorbis. Тест чувствителен как к скорости одиночного ядра, так и к их количеству, и по последнему параметру масштабируется так же хорошо (то есть практически идеально), как и финальный рендеринг.
Используемое ПО:
- dBpoweramp Music Converter R14
- dBpoweramp Reference Codec Pack R3
- dBpoweramp Benchmark
Компиляция
Один из самых существенно переработанных и дополненных разделов, если сравнивать с предыдущей методикой. Во-первых, обновились исходники для компиляции: теперь это Boost — собрание библиотек-расширителей языка C++, которое cвободно распространяется по лицензии Boost Software License вместе с исходным кодом (мы компилируем исходники версии 1.46.0). Выбор именно этого проекта прежде всего был обусловлен тем, что он практически не требует «ручного» подгона для включения многопоточной компиляции. Кроме того, использование «сборщика» BJam позволило отказаться от стандартного make, который в MinGW на большом количестве ядер работает крайне неустойчиво.
Во-вторых, существенно расширился список компиляторов: теперь это не только Microsoft Visual C++, но и gcc (GNU C Compiler, в виде своей Windows-адаптации в пакете MinGW), а также Intel C++ Compiler (в составе Intel Parallel Studio XE 2011) — средство, любимое многими за хорошую «автоматическую» оптимизацию выдаваемого кода. Все три компилятора компилируют одни и те же исходники, поэтому желающие могут получить из наших тестов дополнительную информацию, сравнив их быстродействие между собой (впрочем, это побочный эффект, при разработке методики такой цели не ставилось).
Судя по результатам предварительных тестирований, многопоточная оптимизация весьма хороша во всех трёх тестах, поэтому зависимость результатов от количества ядер CPU в данной группе будет довольно высокой.
Используемое ПО:
- Boost C++ Libraries 1.46.0
- Intel Parallel Studio XE 2011
- Microsoft Visual Studio 2010 Ultimate
- MinGW 11.02.2011
Математические и инженерные расчёты
Данная группа обязана своим названием двум подгруппам входящих в неё тестов: собственно математических пакетов в лице MAPLE и MATLAB, и инженерных CAD с трёхмерными пакетами — хорошо нам знакомых по группе «Интерактивная работа в трёхмерных пакетах» SolidWorks, Creo Elements и Maya. И если с бенчмарками для MAPLE и MATLAB и их связью с вычислениями всё более-менее понятно, то вот относительно CAD у многих может возникнуть вопрос: а они-то тут при чём? Дело в том, что тесты для SolidWorks, Creo Elements и Maya выдают в качестве результата несколько итоговых баллов — «графический», «процессорный» и «ввода-вывода», в которых оценивается производительность тестируемой системы в соответствующих областях. Графический балл этих бенчмарков мы учитываем в группе «Интерактивная работа в трёхмерных пакетах», а процессорный — в группе «Математические и инженерные расчёты».
Из всех используемых в данной группе тестов только бенчмарк для MATLAB имеет более-менее приличную многопоточную оптимизацию, остальные тесты сугубо однопоточные, поэтому чувствительность общего балла к многоядерности будет очень маловыраженной. В прошлой методике в данной группе присутствовал ещё один хорошо многопоточно оптимизированный бенчмарк — MMA 7.0 parallel version для пакета Wolfram Mathematica. К сожалению, из методики-2011 его пришлось исключить. Дело в том, что последняя доступная на момент разработки методики версия пакета — Mathematica 8.0.1, демонстрировала совершенно недопустимую нестабильность результатов: от перезагрузки к перезагрузке ОС, результат выполнения одного и того же теста в этом пакете мог отличаться на 20-30%, причём никакой системы в этих отклонениях не было — первый после включения компьютера результат мог быть и лучше, чем полученный после повторной перезагрузки, и хуже. Естественно, такое поведение однозначно указывало на невозможность использования данного ПО для оценки производительности на регулярной основе.
Используемое ПО:
- Autodesk Maya 2011 x64 SP1
- SPECapc for Maya 2009
- MAPLE 14.01 x64
- Maple version of SciGMark
- MATLAB R2010b (7.11.0) x64
- PTC Creo Elements/Pro 5.0 x64
- OCUS Benchmark V5.1
- SolidWorks 2011 x64 SP2
- SPECapc for SolidWorks 2007
Растровая графика
В методике 2011 года эта достаточно старая и традиционная группа тестов была существенно переработана, причём как состав тестов, так и некоторые из них «внутри себя». По сравнению с 2010 годом исключён только один пакет — Corel PhotoImpact X3 (он уже несколько лет вообще не обновлялся, и, судя по всему, скоро перейдёт в разряд устаревших и не поддерживаемых — Corel, видимо, решила, что PaintShop Photo Pro обладает примерно аналогичной функциональностью, поэтому развивать оба пакета параллельно не имеет смысла). А вот Corel PaintShop Photo Pro «в обойме» остался, да и бенчмарк для него не претерпел никаких изменений. Также практически без изменений остался бенчмарк для Adobe Photoshop, только картинка для подгруппы Filters была заменена на меньшую по размеру — уж больно долго шёл этот подтест на не-топовых процессорах. А вот дальше — сплошные изменения.
Бенчмарк для ACDSee переделан практически полностью. Если наши уважаемые читатели помнят описание методики 2010 года, то там этот пакет занимался конвертацией набора RAW (CR2 и NEF в соотношении 1:1) в JPEG на время. В нынешней методике мы задействовали возможности Batch-обработчика ACDSee максимально полным образом: каждая картинка после преобразования из RAW-формата подвергается обработке полным набором доступных фильтров — поворот, обрезка, изменение размера, автокоррекция цвета, смешивание каналов, сепия, экспозиция, освещение, удаление шума, резкость, виньетка, наложение текста, водяной знак. По субъективным впечатлениям, после переделки бенчмарк существенно более активно задействует дополнительные процессорные ядра, чем раньше.
Добавлен бенчмарк для популярного кроссплатформенного графического редактора GIMP (многие называют его «аналогом Photoshop из мира open source», хотя, как и всякая аналогия, такое сравнение таит в себе массу подводных камней). Как и в случае с ACDSee, тестирование заключается в пакетной обработке массива фотографий с помощью различных эффектов. Это наш первый опыт с GIMP, поэтому набор накладываемых фильтров пока небольшой: устранение шумов, изменение размера, резкость (unsharp mask). Кстати, мы будем рады, если среди наших читателей найдутся профессионалы по работе с GIMP — общими усилиями у нас есть все шансы сделать этот тест ещё интереснее.
Ещё один (и снова кроссплатформенный и open source) добавленный пакет — ImageMagick. Это ПО предназначено уже сугубо для пакетной обработки растровых изображений из командной строки, поэтому методика тестирования очевидна. В нашем случае используется следующая последовательность фильтров: резкость (unsharp mask), изменение размера, автокоррекция цвета, нормализация.
Многопоточная оптимизация у разных приложений (и конкретных тестов) в данной группе существенно различается. Условно её можно разделить на три вида: хорошую (ImageMagick), удовлетворительную (ACDSee и Photoshop), и практически отсутствующую (GIMP и PaintShop Photo Pro).
Используемое ПО:
- ACDSee Pro 3.0 build 475
- ACDSee RAW Plugin 4.1 build 295
- Adobe Photoshop CS5 x64
- Corel PaintShop Photo Pro X3
- GIMP 2.6.10 x64
- ImageMagick 6.6.7 x64 static
Векторная графика
Не без активной помощи наших читателей претенциозное название предыдущего раздела методики обрело наконец-таки свой изначально предполагавшийся смысл: в дополнение к графике растровой в списке групп тестов появилась группа графики векторной, причём она включает в себя бенчмарки для двух наиболее популярных пакетов: Adobe Illustrator и CorelDraw. Как и в случае с Adobe Photoshop, методика тестирования предполагает выполнение «на время» некоего скрипта, который загружает изображение (в нашем случае — векторное) и производит над ним некоторое количество операций. Наверное, по изысканности, наполненности и проработанности деталей эти скрипты ещё нельзя сравнивать с нашим бенчмарком для Adobe Photoshop (который, скромно напомним, разрабатывается уже более 5 лет), однако начало положено, и это не может не радовать. С сожалением вынуждены отметить, что первые пробные тестирования дали достаточно однозначный ответ на «главный вопрос современности» — да, оба самых знаменитых векторных пакета до сих пор остались чисто однопоточными приложениями, никакой способностью задействовать более одного процессорного ядра там и не пахнет.
Используемое ПО:
- Adobe Illustrator CS5
- Скрипт и исходники для тестирования Illustrator
- CorelDraw Graphics Suite X5 SP2
- Скрипт и исходники для тестирования CorelDraw
Кодирование видео
Эта опять-таки традиционная для нашей методики группа практически не претерпела изменений: один тест был исключён, один добавлен. Исключили мы DivX, т. к. последние несколько лет кодек не блистал ни оптимизацией, ни оригинальностью результатов, да и вообще эпоха кодеков MPEG-4 ASP, кажется, подходит к концу. XviD пока всё же остался — как дань более чем широкой распространённости закодированных им материалов на всевозможных торрент-трекерах и всё ещё остающейся актуальной совместимости с бытовыми DVD-плеерами, к H.264/MKV относящимся с заметной прохладцей. Добавлен был Microsoft Expression Encoder как образец бесплатного (да-да!) ПО, обеспечивающего кодирование в достаточно современный стандарт VC-1 (являющийся, по сути, единственной реальной альтернативой H.264). Прочие бенчмарки остались без изменений (за исключением обновлённых версий ПО). Многопоточная оптимизация в данной группе достаточно хороша: мы бы сказали, что, в зависимости от используемой программы, она варьируется от «довольно неплохо» до «отлично».
Используемое ПО:
- Adobe Premiere CS5 (5.0.3) x64
- Microsoft Expression Encoder 4
- Sony Vegas Pro 10.0c x64
- x264 rev 1924
- XviD 1.30 RC1
- AviSynth 2.5.8
- VirtualDub 1.10.0
Офисное ПО
Совершенно новая группа, которой не было ни в одной предыдущей методике. Правда, некоторые отдельные тесты нашим постоянным читателям покажутся знакомыми: бенчмарк Google V8 в комбинации с браузерами Internet Explorer, Mozilla Firefox, Google Chrome и Opera присутствовал в предыдущей методике в группе «Браузеры». Сейчас, в связи с появлением отдельной группы офисного ПО, нам показалось верным включить достаточно саму по себе узкую браузерную группу в состав более широкой. Кроме четырёх браузеров, в офисную группу вошли три составляющих из пакета Microsoft Office 2010: Excel, PowerPoint и Word, а также ABBYY FineReader — самая популярная в России и «ближнем зарубежье» система оптического распознавания символов.
Наибольшее количество проблем было с бенчмарками для программ из пакета Microsoft Office: очень трудно найти задачу, время выполнения которой даже на самой слабой системе оказалось бы критичным — а иначе какой смысл в тестировании? В случае с Excel нам помог всемогущий Google, выдав по запросу «excel benchmark» ссылку на страницу с довольно интересной (по крайней мере на первый взгляд) разработкой. Желающим подробностей рекомендуем ознакомиться с первоисточником по указанной ссылке, если же вкратце — это таблица с данными, по которым в процессе выполнения бенчмарка строится динамично меняющийся график. Общее время его построения и является результатом теста. Случаи PowerPoint и Word оказались намного более запущенными, поэтому пришлось придумывать самим, и придумалась нами хоть и довольно банальная, но, по крайней мере, единственная действительно долгая операция, которую мы смогли отыскать: импорт презентации (PowerPoint) или текста (Word) в формат PDF. Однако, сами осознавая некоторую ограниченность использованного нами подхода в плане задействования функциональности тестируемого ПО, мы с удовольствием послушаем критиков — особенно всё, что будет идти после слов «…а вместо этого я предлагаю…»
Тест для FineReader (кстати: единственный хорошо распараллеливаемый бенчмарк в офисной группе) — представляет собой распознавание «на время» коллекции номеров журнала «Микропроцессорные средства и системы» за 1986 год, представленной в формате DjVu.
В целом, можно констатировать, что офисная группа пока не представляет собой 100% совершенства — как с точки зрения ассортимента ПО, так и с точки зрения информативности некоторых бенчмарков. Однако группа появилась, а значит — появился стимул для будущих улучшений, переделок, дополнений — словом, всего того, через что уже прошли более «старые» тестовые наборы в нашей методике.
Используемое ПО:
- ABBYY FineReader 10
- Microsoft Office Professional Plus 2010
- ExcelTrader Excel Benchmark
- Google Chrome 10.0.648.204
- Microsoft Internet Explorer 9
- Mozilla Firefox 4.0 x86
- Opera 11.01
- Google V8 Benchmark Suite
Java
Никаких изменений по отношению к методике 2010 года — мы по-прежнему используем бенчмарк SPECjvm2008. Он достаточно подробен и включает много подтестов из самых разных областей: Compiler (компиляция с помощью OpenJDK), Compress (сжатие данных по методу LZW), Crypto (шифрование по протоколам AES/DES, RSA, верификация по методам MD5 with RSA, SHA1 with RSA, SHA1 with DSA и SHA256 with RSA), Derby (тест использует open source БД, целиком написанную на Java), MPEGAudio (декодирование mp3 на базе LGPL-библиотеки JLayer), Scimark (популярный в научной среде бенчмарк вычислений с плавающей точкой — кстати, мы используем его адаптированную под MAPLE версию в соответствующем тесте), Serial (параллельно-последовательное преобразование), Sunflow (визуализация с помощью многопоточно-оптимизированного движка рендеринга с поддержкой global illumination), XML (наложение таблиц стилей на XML-документы и валидация XML-документов по схеме xsd). Бенчмарк очень хорошо многопоточно оптимизирован, и соответственно, поскольку он является единственным в группе, средний балл также сильно зависит от количества процессорных ядер в тестируемой системе.
Используемое ПО:
- Sun JRE Version 6 Update 23 x86/x64
- SPECjvm2008 1.01
Игры
Игровой раздел нашей методики по сравнению с 2010 годом, пожалуй, поредел сильнее всего: 6 игр вместо прошлых 11. С другой стороны, это отражает пусть и печальную, но вполне объективную тенденцию: всё большее количество игр «уходит» на приставки (где бенчмаркинг видится делом достаточно бессмысленным, ибо результаты у всех будут одинаковые), а соответственнно — всё меньше хороших игр для ПК, а среди них ещё меньше тех, которые содержали бы встроенные инструменты для измерения производительности (наше мнение о целесообразности использования утилит типа FRAPS мы уже озвучивали, и с тех пор ничего не изменилось).
Основные «идеологические» установки тестирования остались неизменными: в играх используются высокие настройки качества графики и разрешение 1680×1050, т. к. нет никакого смысла тестировать мощно оснащённые тестовые стенды (в стандартном комплекте — 8 ГБ ОЗУ плюс видеокарта на базе NVIDIA GeForce GTX 570) на низких разрешениях и с упрощённым качеством. Впрочем, специально имея в виду ноутбуки, неттопы и готовые системы нижнего уровня, мы ввели опциональный тест: те же игры, но с низким разрешением и качеством графики. Этот тест является стандартным, его результаты заносятся в таблицу, но не влияют ни на общий балл в игровой группе, ни на средний общий балл. Что, впрочем, не мешает на них посмотреть тем, кому они интересны.
Многопоточная оптимизация в среднем по группе обещает оказаться довольно неплохой (и это, несомненно, общая тенденция для данной разновидности ПО), но распределение по отдельным бенчмаркам весьма неравномерно, вплоть до полного отсутствия.
Используемое ПО:
- Aliens vs. Predator
- Aliens vs. Predator D3D11 Benchmark 1.03
- Batman: Arkham Asylum GOTY Edition
- Crysis: Warhead x64
- Framebuffer Crysis Warhead Benchmarking Tool 0.40
- F1 2010
- Far Cry 2
- Metro 2033
- Steam
- Конфигурационные файлы игр или бенчмарков
Дополнительная группа
Эта группа включает в себя тесты, которые входят в стандартную методику тестирования (то есть, если нет никаких дополнительных доводов «против», их обязаны пройти все участвующие в тестировании системы), результаты этих тестов, наравне с результатами основной группы, включаются в общую таблицу — однако входящих в основную группу подгрупп они не образуют, и на общий средний балл никак не влияют. Как правило, вынесением в дополнительную группу тесты обязаны одной из двух причин: либо их результаты достаточно интересны только в некоторых конкретных случаях, но отнюдь не во всех, либо это относительно новый тест, поэтому мы предполагаем, что его результаты могут быть интересны, но, ввиду отсутствия достаточного количества статистики, не уверены в этом предположении полностью. В последнем случае тест будет корректнее называть даже не «дополнительным», а «экспериментальным».
Проигрывание видео высокой чёткости
Этот тест выдаёт в качестве результата загрузку процессора во время воспроизведения HD-видео (фрагмент фильма «Iron Man», 1920×1080, H.264) в двух различных плеерах, с включенной поддержкой DXVA (позволяет задействовать для декодирования мощности GPU) и в режиме чисто программного декодирования (только силами CPU). Включать данную группу в список основных мы не видим никакого смысла, т. к. начиная с определённого (и довольно низко находящегося) предела производительности разница в загрузке CPU между двумя различными системами не является для конечных пользователей значимой: ну, подумаешь, не 24%, а всего 16% — ну и что? Видео не «дёргается» — значит, всё хорошо. Таким образом, результаты этого теста становятся интересными только в том случае, когда они вплотную приближаются к 100%, а то и превосходят их — чего в подавляющем большинстве случаев (особенно с десктопами, на которые методика тестирования по-прежнему ориентирована больше всего) не произойдёт.
Кстати, разъясним, почему этих процентов иногда будет оказываться более 100. Здесь придётся объяснить, как на самом деле они считаются. Фактически, мы получаем от специальной утилиты 2 значения: длительность процесса, и длительность процессорного времени, потраченного на его выполнение. В случае с одним ядром, понятное дело, второе больше первого быть не может. А вот уже с двумя ядрами — разумеется, может. Предположим, процесс длился всего 5 минут, а потрачено было на него 5 минут работы одного ядра, и ещё 2 минуты другого — вместе, соответственно, 7. Таким образом, в случае с 2-ядерным процессором, максимальная загрузка будет составлять 200%, в случае с 4-ядерным — 400%, и так далее.
Степень оптимизации процесса проигрывания в обоих плеерах под многоядерные архитектуры остаётся для нас не очень ясной, но опираясь на предыдущий опыт тестирований, мы бы сказали, что особенных чудес ждать не стоит, и скорее всего она окажется довольно-таки низкой.
Используемое ПО:
- Media Player Classic Home Cinema 1.4.2499.0 x86
- VLC Video Player 1.1.7
Многозадачное окружение
Несмотря на то, что этот тест базируется на реальном ПО (а ещё точнее — одновременно на нескольких бенчмарках, входящих в различные группы тестов нынешней методики), по сути, мы бы назвали его «полусинтетическим». Почему? Потому что когда мы говорим о «реалистичности» нашей методики тестирования, мы имеем в виду достаточно широкий смысл: заранее чётко предопределённые, каждый раз одни и те же действия, достаточно часто встречающиеся в процессе практической деятельности многих пользователей, или же их имитация, приводящая, насколько это возможно, к примерно аналогичному распределению результатов тестирования. Поэтому если мы, например, исследуем скорость упаковки файлов с помощью архиватора 7-Zip — то мы создаём более-менее реалистичный набор файлов, и упаковываем их «на время» с помощью архиватора 7-Zip, а не пользуемся встроенным бенчмарком этого архиватора (несмотря на то, что он там есть) — потому что первый способ реалистичнее. Разумеется, иногда приходится идти на уступки, однако мы стараемся делать это исключительно в тех случаях, когда альтернативой является полный отказ от использования теста как такового.
Можно ли составить универсальный список из нескольких параллельно выполняемых задач? Разумеется невозможно! Потому что сколько пользователей — столько различных комбинаций программ, да и в случае с одним и тем же пользователем, вполне вероятно, сегодня комбинация будет одной, а завтра — другой. Поэтому мы и не пытались. Соответственно, наш список бенчмарков для данного раздела методики — это… просто некий список. Его даже можно назвать случайным, хотя это и не совсем так — мы постарались отобрать бенчмарки, относящиеся к разным группам, максимально стабильные в работе, по возможности сами по себе достаточно неплохо многопоточно оптимизированные, удобные для осуществления точного замера результата, чтобы их результаты были представлены в одних единицах измерения, и чтобы время выполнения одиночных бенчмарков было по возможности сопоставимо (хотя бы не различалось на порядки). Получился следующий список:
- Растровая графика: GIMP
- Финальный рендеринг трёхмерных сцен: Maya
- Компиляция: MSVC
- Кодирование видео: XviD
- Упаковка и распаковка: упаковка 7-Zip
Суть теста проста: все бенчмарки запускаются в указанном в списке порядке, практически одновременно (с паузой в 15 секунд), при этом всем задачам присваивается «фоновый» статус (ни одно окно не является активным). Результатом является среднее геометрическое времён выполнения всех 5 тестов. Причина включения данного раздела в методику в двух словах описывается довольно просто: нам интересно. То есть, конечно же, некие вполне определённые ожидания у нас с результатами теста связаны, но оправдаются ли они в полном объёме, и не обнаружится ли что-нибудь интересное дополнительно — этого мы и сами пока не знаем. Поэтому сейчас мы видим свою скромную задачу в том, чтобы собрать достаточно объёмную статистику результатов и потом внимательно её проанализировать.
Используемое ПО:
- 7-Zip 9.20 x64
- Autodesk Maya 2011 x64 SP1
- GIMP 2.6.10 x64
- Microsoft Visual Studio 2010 Ultimate
- XviD 1.30 RC1
- AviSynth 2.5.8
- VirtualDub 1.10.0
активным участникам обсуждения будущей
методики тестирования, без помощи которых
она была бы намного менее совершенной:
Rubanetz Miroslav за помощь с тестами компиляции;
vytian за скрипт для тестирования CorelDraw;
caliostro за скрипт для тестирования Illustrator;
MerovingL за ссылку на сцену для 3ds max + V-Ray;
Netmaster за наводку на пакет ImageMagick.
