Сказ о том, как Phoenix тестирует комплектующие в играх
реклама
Вместо вступления
Я долго терпел, но теперь накипело… Многие читатели задают вопрос, как мне удается проводить такое количество тестов, и высказывают сомнения в их объективности. Поэтому мы решили рассказать об этом более подробно. В данном материале будет продемонстрирована работа моих тестовых стендов и рассказано о методике тестирования и обработке полученных результатов.
Тут не будет веселых картинок, а будет краткий рассказ по сути и пара примеров, которые должны снять подавляющее большинство вопросов у всех разумных читателей.
реклама
Как получается так много результатов?
Начну с видеоролика, на котором запечатлена одновременная работа моих тестовых стендов. В нем параллельно тестируется по пять игр на каждом стенде. При этом я не вмешиваюсь в их работу, они функционируют в полностью автоматическом режиме.
Помимо двух стендов на видео фигурирует мое рабочее место, на котором я могу параллельно обрабатывать результаты тестов и заниматься оформлением обзоров для лаборатории.
реклама
Чем хороши два автоматических стенда, способных работать одновременно, без моего участия в тестах?
Прежде всего, за один час они могут протестировать от 24 до 30 тестовых отрезков. При этом на смену комплектующих в среднем уходит около 10 минут. Мой рабочий день длится от восьми до четырнадцати часов в зависимости от объема тестов, необходимых для оформления запланированных материалов. Рабочая неделя шестидневная.
В результате, с учетом времени, затраченного на смену комплектующих, в неделю можно протестировать от 1200 до 2400 отрезков. При этом на написание новых скриптов, их обкатку на стендах, обработку результатов тестов и оформление материалов у меня в распоряжении от 40 до 80 часов.
Благодаря бесперебойной работе двух автоматических стендов (и моему трудолюбию, само собой ), моя рабочая неделя соответствует труду четырех-пяти людей, тестирующих комплектующие вручную и параллельно (или последовательно) выполняющих оформительскую работу.
Теперь рассмотрим вопрос о том, за счет чего мне удалось полностью автоматизировать работу двух тестовых стендов. Для этого используются скрипты, аналогичные тем, что мы впервые опробовали с другим автором лаборатории Ivan_FCB еще несколько лет назад. Вот ссылки на статьи с подробным рассказом о них:
- Автоматизируем процесс замера производительности в играх;
- Автоматизируем процесс замера производительности в играх (продолжение);
- Автоматизируем процесс замера производительности в играх (часть 3).
Основываясь на этой методике, создаются скрипты, которые позволяют полностью автоматизировать процесс тестирования любой игры. При этом с помощью данных скриптов можно менять настройки графики и разрешения в тестовых приложениях.
Утилита AutoHotkey очень удобный инструмент автоматизации процесса тестирования. Благодаря ей в играх с отсутствующими бенчмарками при нескольких прогонах игрового отрезка я добился разброса результатов около 4%. Этот показатель ни в чем не уступает большинству игр со встроенными бенчмарками, а иногда и лучше, чем у некоторых проектов.
В результате, последние два года при тестах более чем 90% игр я использую всего один прогон тестовой сцены. Это заметно сократило время, затрачиваемое на подготовку к публикации многих обзоров.
Помимо ранее указанных плюсов, AutoHotkey позволяет объединять в единую цепочку тестов любое количество игр, что практически полностью исключает участие человека в рабочем цикле стенда. Это открывает новые горизонты в рабочем цикле профессионального тестера и по совместительству автора статей.
Как тестируются процессоры
Теперь расскажу о том, как я тестирую процессоры, и откуда берется большое количество моделей в моих трудах. Все очень просто. В большинстве случаев используются модели ЦП со свободным множителем: К и ВЕ серии. Не нужно тестировать множество одинаковых CPU, если их можно симулировать на одной модели, выставив на ней частоты, соответствующие конкретным версиям. При этом экономится много времени на смене процессоров и значительно продлевается срок службы материнских плат.
Важным моментом является то, что симуляция разных моделей ЦП происходит с помощью процессоров, полностью соответствующих архитектуре эмулируемой серии. То есть для симуляции процессоров Core i5 используется старшая модель данной серии, например Core i5-6600K. Для тестов восьмиядерных процессоров AMD используется модель FX-9590 BE и так далее, в том же духе.
Единственным слабым местом во всей этой затее являются технологии Turbo Boost и Turbo Core. Решается данная проблема очень просто. Старшая модель со свободным множителем, работающая в номинальном режиме, тестируется с включенной и выключенной технологией Turbo Boost. Далее этот же ЦП тестируется с частотами эмулируемых моделей, но при выключенной технологии Turbo Boost. В завершении к полученным результатам добавляется разность производительности включенной и выключенной технологии Turbo Boost, полученной в самом начале тестов. При этом учитывается величина повышения тактовой частоты CPU при включенной технологии Turbo Boost.
Процесс тестирования
Теперь поговорим непосредственно о самом тестировании комплектующих, и что оно собой представляет. Для этих целей используется четыре типа тестовых отрезков:
реклама
- Встроенные бенчмарки;
- Кат-сцены, созданные на игровом движке;
- Игровые сцены, в которых антагонист передвигается по локации вслед за собеседником. Это очень редкое явление в современных играх, однако время от времени подобные проекты попадают в мои тесты;
- Игры, в которых персонажи и техника передвигаются с помощью скрипта AutoHotkey.
Целью любого тестирования, будь это встроенный в игру бенчмарк или ручной тест комплектующих в определенных игровых отрезках, является минимальный разброс результатов при нескольких прогонах той или иной сцены. Я считаю данный параметр приемлемым, если он не превышает погрешности +/- 4%. Первые три пункта, указанные выше, соответствуют данной величине в большинстве случаев.
Теперь поговорим о четвертом пункте, вернее о преимуществах использования автоматических скриптов AutoHotkey. Благодаря данной утилите передвижение персонажей или техники можно запрограммировать таким образом, что разброс результатов после нескольких прогонов одной тестовой сцены не будет уступать встроенным игровым бенчмаркам.
Однако есть очень важный нюанс: все передвижения персонажа скриптуются исключительно с помощью клавиатуры. Мышь в этом процессе вообще не участвует. То есть в подавляющем большинстве игр при перемещении персонажей или техники камера смотрит в одном направлении, никуда не поворачивая.
Еще во времена, когда я тестировал комплектующие вручную, мною была отмечена закономерность: при нескольких прогонах игровой сцены даже небольшой поворот камеры приводил к разбросу результатов от 7% до 10%. Активное вращение камерой при длительной тестовой сцене увеличивал разброс результатов до 20% и более. Объективными такие тесты можно назвать с очень большой натяжкой.
В некоторых играх, которые тестировались мною, есть-таки небольшие вращения камеры. Однако это редкие случаи, когда они минимально влияли на разброс результатов. Все дело в том, что в таких проектах можно поворачивать персонажем или техникой при помощи клавиатуры. Причем есть возможность запрограммировать поворот на 5 градусов и даже меньше. Время нажатия на клавишу, отвечающую за поворот, жестко фиксируется, а его величину можно настроить вплоть до нескольких миллисекунд.
Когда люди пытаются апеллировать результатами тестов с сомнительных ресурсов, полученных вручную, я им доверяю меньше. Как раз из-за той самой камеры, привязанной к персонажам или технике. Зачастую «тестеры» бегают по локациям, делая резкие развороты на 90, а то и 180 градусов. Понятно, что это чревато большим разбросом результатов.
В стародавнюю пору подобные тесты считались «не комильфо», однако с увеличением количества игр, в которых интересно увидеть результаты тестов, многие читатели стали закрывать на это глаза. Например, на эту тему можно почитать мой старый материал: «Современные методы тестирования комплектующих в играх».
Более двух лет я занимался ручными тестами игр. Считать подобные тесты эталоном объективности не стоит. Они дают представление о производительности конфигураций в целом, но сравнивать результаты с точностью до процентов при этом наивно.
Понятно, что и при моей методике, и особенно таких объемах получаемых данных возможны неточности, которые могут быть вызваны самыми разными причинами. Однако большинство претензий на самом деле не обоснованы. И это приводит нас к вопросу о восприятии результатов тестов.
Восприятие результатов тестов
Очень часто люди пытаются сравнивать производительность комплектующих, опираясь на разные источники. При этом во многих случаях начинаются пересуды: «эти тесты правильные, а эти неправильные».
Грамотные пользователи прекрасно знают, что даже на схожих конфигурациях результаты тестов никогда не совпадут. Почему? На это влияет огромное количество факторов:
- Конфигурация тестового стенда;
- Версия операционной системы;
- Версия драйверов видеокарт;
- Версия драйверов материнской платы;
- Версия BIOS материнской платы;
- Частота и тайминги оперативной памяти;
- Дополнительное программное обеспечение, установленное на стенд;
- Версия игры;
- Исправность комплектующих, принимающих участие в тестах;
- Разброс результатов тестов при многократном прогоне тестового отрезка;
- Множество других факторов, способных заметно повлиять на результаты тестов.
В далеких 2007-2008 годах у меня был свой проект в нашей конференции. В сотрудничестве с большим количеством ее участников было протестировано несколько игр. Я принимал результаты, обрабатывал и оформлял их в виде сводных диаграмм. Затем выкладывал в конференции в специально созданной теме.
Именно при обработке результатов, полученных от разных людей, я убедился, что производительность казалось бы схожих конфигураций может сильно отличаться. Это и стало отправной точкой, подтолкнувшей меня к самостоятельным исследованиям.
Поэтому любые тесты следует рассматривать с позиции их привязки к конкретной конфигурации. А информацию из разных источников воспринимать как справочную, для расширения кругозора своих познаний.
Пара примеров
Теперь рассмотрим еще один важный момент тестирования: возможность и невозможность тех или иных результатов тестов. Так, например, существует мнение, что разогнанная видеокарта GeForce GTX 980 в принципе не способна догнать старшую модель GeForce GTX 980 Ti, работающую в штатном режиме. Его разделяют и некоторые наши читатели.
Это миф, например, можно посмотреть на диаграмму (Core i7-6700K @ 4600 МГц + 16 Гбайт DDR4 @ 3000 МГц, разрешение 1920 х 1080):
Battlefield 4
Номинал
Включите JavaScript, чтобы видеть графики
Разгон
Включите JavaScript, чтобы видеть графики
Grand Theft Auto V
Номинал
Включите JavaScript, чтобы видеть графики
Разгон
Включите JavaScript, чтобы видеть графики
Homefront The Revolution
Номинал
Включите JavaScript, чтобы видеть графики
Разгон
Включите JavaScript, чтобы видеть графики
Project CARS
Номинал
Включите JavaScript, чтобы видеть графики
Разгон
Включите JavaScript, чтобы видеть графики
Stronghold Crusader 2
Номинал
Включите JavaScript, чтобы видеть графики
Разгон
Включите JavaScript, чтобы видеть графики
Если рассматривать исключительно технические характеристики видеокарт, то в теории получается, что GeForce GTX 980 Ti быстрее GeForce GTX 980 приблизительно на треть. И у разогнанной младшей версии действительно нет шансов догнать старшую модель.
Однако в реальности это не так. Производительность любых видеокарт серьезно ограничивает мощность процессоров. По диаграмме видно, что чем более процессорозависима игра, тем значительнее ЦП сдерживает потенциал видеокарт. И в самых неблагоприятных условиях GeForce GTX 980 Ti и GeForce GTX 980 показали одинаковый результат, хотя в теории это невозможно.
Или вот еще один миф: о фантастическом увеличении производительности видеокарт после их разгона в некоторых играх. Перечислю факторы, влияющие на эту величину:
- Версия драйверов видеокарт;
- Процессорозависимость той или иной игры. Ограничения, накладываемые процессором на мощность видеокарт, напрямую влияют на производительность после их разгона;
- Оптимизация той или иной игры под конкретного производителя видеокарт;
- Погрешность в результатах тестов после нескольких прогонов игрового отрезка.
Внимательнее рассмотрим последний пункт. Ранее я упоминал о том, что считаю приемлемым разброс результатов +/- 4%. Допустим при разгоне GeForce GTX 980 процессор минимально влиял на ее мощность, и ее производительность выросла в среднем на 14%. Но при этом (во время тестов данной видеокарты в номинальном режиме работы) был получен разброс результата «-2%», а после разгона – «+3%». Вследствие чего в финальную версию обзора попал рост производительности на 19%.
На первый взгляд это слишком большое значение, однако разброс результатов при тестах разных режимов работы видеокарты не превысил допустимые +/- 4%.
Отсюда следует вывод о том, что не стоит воспринимать любые результаты тестов как истину последней инстанции. Идеальных тестов в природе не существует. Поэтому при изучении того или иного обзора стоит помнить, что в тестах присутствует допустимое отклонение результатов.
Вместо заключения
Уважаемые читатели, в данном материале я рассказал и наглядно показал процесс тестирования комплектующих, а также поведал о важных нюансах, которые необходимо учитывать при обработке результатов.
Надеюсь, все разумные читатели при помощи него получат ответы на основные свои вопросы. Пожалуй, и вправду резонные – наверняка далеко не все следят за историей развития методик тестирования игровой производительности в лаборатории Overclockers.ru. Да и я, каюсь, за массой результатов со временем немного позабыл о подаче и восприятии своей работы со стороны. Что ж, теперь ссылка на данный материал будет сопровождать каждое мое тестирование и, надеюсь, сведет вопросы о собственно тестировании к минимуму.
Благодарю за помощь в подготовке материала к публикации: donnerjack.
реклама
Страницы материала
Лента материалов раздела
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии 186 Правила