Методика тестирования компьютерных систем образца 2020 года: старые принципы — новые решения
Процесс смены методик тестирования компьютерных систем сильно затянулся, однако дошел до логического завершения — почти на год позже, чем планировалось. В процессе доработки тестовых задач и адаптации их для новых версий программного обеспечения, возникли определенные трудности. Затем некоторые программы обновились в очередной раз — и снова я на Дерибасовской… В конечном итоге было принято волюнтаристское решение остановиться на достигнутом на некоторое время — благо состояние, в котором «всё работает» и пригодно для практических целей, было достигнуто.
Почему вообще приходится регулярно проделывать такую работу? Потому что, вообще говоря, освоение новых аппаратных возможностей программистами происходит с заметным лагом относительно их внедрения. У большинства пользователей сначала «нового железа» нет вообще, а потом оно начинает появляться, но на фоне общего количества используемых компьютеров погоды не делает. Даже серверы принято заменять лишь раз в пять лет, а настольные системы иногда работают и дольше. Но чем дальше, тем больше увеличивается превосходство «новейших» систем — поскольку все большее количество ПО «обучается» правильной работе с ними. А вот результаты «устаревших» компьютеров при смене программного обеспечения не улучшаются — бывает, даже и наоборот. Однако тестировать приходится и те, и другие: новые — потому что они новые, а старые — чтобы понимать, чем они хуже новых. Слишком «частить» со сменами тестовой методики тоже плохо — ведь целью-то являются не абстрактные результаты в вакууме, а сравнение разных компьютерных систем. Как минимум — их компонентов. В первую очередь — центральных процессоров. И чтобы не перетестировать их раз за разом, тестовую методику приходится фиксировать на продолжительный срок — как минимум, на год-два. Что мы и делаем.
Текущая версия методики в основном была разработана в 2019 году. Использовать мы ее тоже начали до Нового года — однако основная работа придется на 2020-й и, возможно, первую половину 2021 года. Данный материал является описанием новой методики, причем в первую очередь посвящен не способам измерения производительности и других параметров (это тоже довольно объемные вопросы, заслуживающие отдельных статей — часть из которых уже написана), а тому, как они будут использоваться непосредственно в серии обзоров. Иными словами, основной темой для нас сегодня будет не «как», а «почему так — и не иначе». Соответственно, теоретическая часть в очередной раз практически не изменилась и будет повторена почти дословно — можно было бы ограничиться ссылками на описания предыдущих тестовых методик, но, как показала практика, те, кому это в наибольшей степени нужно, по ссылкам не ходят, а информация на деле крайне важна для понимания процесса, да и результатов тоже. Чтобы в будущем не возвращаться к подобным вопросам, сегодня мы постараемся дать на них полные ответы. Во всяком случае, в той части, которая традиционно относится к тестированию центральных процессоров. Начнем прямо с названия.
Как измерить то, чего не существует?
Этот провокационный заголовок полностью раскрывает проблему. Действительно: что такое «производительность»? Количественная характеристика скорости выполнения определенных операций. Из чего сразу же следует основной вывод: никакой «производительности процессора» не существует. В отличие от, например, производительности компьютера. Просто потому, что последний является законченным устройством, на практике способным выполнять какие-либо вычисления и все, что к ним сводится. Разумеется, многое зависит от операций, скорость которых измеряется, т. е. программного обеспечения. Которое еще и работает только под управлением определенных операционных систем, что дополнительно сужает предметную область. Однако выбрав ОС и программы, мы можем получить для аппаратной системы какой-то более или менее осмысленный результат. И даже сравнить разные системы по производительности на выбранном наборе программного обеспечения.
Но если спуститься на уровень ниже, т. е. перейти от законченных устройств к компонентам, понятие производительности очевидным образом просто исчезает, поскольку ни к какому отдельному использованию компоненты не пригодны. Во всяком случае, не к целевому. Винчестер можно использовать как гнет при закваске капусты, а процессор — чтобы пускать «блинчики» по воде, однако их «производительность» при выполнении подобного рода «операций» никого не интересует. А та, которая интересует, может быть измерена лишь в рамках законченной системы и потому будет испытывать влияние других компонентов, а зачастую именно они окажутся определяющими. Например, при недостаточном для решения какой-то задачи количестве оперативной памяти любые процессоры «тормозить» будут одинаково — узким местом станет работа с виртуальной памятью. Иногда в таких ситуациях дело доходит до смешного: ограничение количества активных процессорных ядер увеличивает производительность, поскольку памяти в таком случае начинает «хватать».
А уж какое влияние на итоговую производительность компьютера в современных условиях могут оказывать видеокарты — вообще отдельный разговор. Речь даже не об играх — с ними-то все просто: как правило, именно в видеосистему все и «упирается», а остальные компоненты как-то сказываются лишь тогда, когда ее мощность избыточна для выбранного режима. Однако задействовать в работе GPU за последнее время научились и программы общего назначения. Причем задействовать по-разному: кто-то «крутит» OpenCL-код на всех графических процессорах, а кто-то ограничивается выделенными блоками для декодирования или кодирования видео. Или даже для обратной трассировки лучей — есть уже и такие примеры. И тут важнейшим фактором может оказаться совместимость конкретной программы с конкретной линейкой GPU (как на уровне железа, так и в плане возможностей видеодрайвера). В итоге нередки парадоксальные ситуации, когда установка мощной дискретной видеокарты снижает производительность относительно использования простенького встроенного графического ядра — как раз потому, что последнее в конкретной программе использовалось, а дискретка для тех же операций «не подцепилась». Иногда это исправимо настройками, иногда (в особенности если говорить о программах бытового назначения) — нет. В последнем случае имеет смысл сначала подобрать видеокарту, а потом уже к ней подходящий процессор. Почти как в игровом ПК — с той лишь разницей, что все игры «совместимы» с любыми видеокартами, а вот неигровое ПО — не обязательно со всеми и не обязательно одинаково.
Почему же в таком случае все равно можно говорить о «производительности процессоров»? Потому что тестовые конфигурации можно привести к более-менее одинаковому состоянию (во всяком случае, это верно для модульных систем — типа настольных). В идеале — добиться того, что различаться они будут исключительно процессорами. Такое возможно, например, если тестируются два устройства для одной и той же платформы: будучи установлены на одну и ту же системную плату и снабжены одной и той же «периферией» (от оперативной памяти до накопителей), работать они будут со скоростью, зависящей только от них самих и/или ограниченной прочими компонентами одинаковым образом. Последняя проблема не является неразрешимой при наличии гибкости в конфигурировании, поскольку «вредные» факторы при обнаружении можно исключить. Однако и в этом случае мы измеряем не производительность процессора, а производительность всей системы.
В определенных условиях этим можно пренебречь. Например, можно утверждать, что в рамках одной платформы один процессор быстрее другого в полтора раза, если скорость выполнения набора тестовых заданий при замене одного на другой меняется в указанные полтора раза. Вот с другими характеристиками (зачастую не менее интересными) нужно быть уже очень осторожным. Например, не имеют никакого смысла попытки посчитать «соотношение цены и производительности», ориентируясь только на цену процессоров. Действительно: если модель X работает в полтора раза быстрее, чем модель Y, а стоит вдвое дороже, то, казалось бы, по пресловутому соотношению она заметно хуже. Но если вспомнить, что на деле мы можем получить только производительность системы, то приходим к выводу, что учитывать нужно цену именно системы. И если, к примеру, X стоит $50, Y — $100, а все остальное оборудование, которое использовалось в тестах — $450, значит, увеличение производительности на 50% происходит при увеличении цены всего лишь на 10%, так что более дорогой процессор на самом деле является более выгодной покупкой. А что будет при сравнении этих же двух процессоров, когда на «окружение» потрачено $250 или $750? Строго говоря, мы не знаем. Одно тестирование в конкретных условиях не дает ответа на вопрос, как изменится производительность в общем случае. Может выйти так, что слишком дешевая система приведет к одинаковым результатам для обоих процессоров, а в более дорогой разница увеличится (при этом разница в реальной цене систем сократится), может — наоборот (на самом деле нет), а может — ничего не изменится. Информации недостаточно.
Так что, как видим, даже в рамках одной и той же платформы при возможности полностью уравнять условия тестирования все не так уж просто. А ведь как раз такие сравнения наименее интересны, поскольку их результаты слишком предсказуемы. Куда больше пользы — от сравнения процессоров для разных платформ одного производителя (благо таковые регулярно обновляются) или вообще разных платформ разных разработчиков для разных сфер применения. В этом случае добиться одинаковых условий тестирования просто невозможно, как ни старайся. Скажем, системные платы в таком случае будут разными по определению, и хотя их влияние на производительность системы обычно (давно уже) отсутствует, мы сталкивались с обратными ситуациями. Да и цены материнских плат будут влиять на общую картину: например, более дешевый, на первый взгляд, процессор окажется более дорогим с учетом стоимости всей системы, поскольку в паре с ним придется использовать более дорогую плату, а то еще и дискретную видеокарту в обязательном порядке.
В итоге нет смысла пытаться всегда привести всё к «общему знаменателю». А в некоторых случаях это не нужно, даже когда возможно, поскольку такое «рафинированное» тестирование «в вакууме» будет слабо соотноситься с реальными условиями. Все, что требуется — постараться обеспечить сравнимые характеристики тестовых платформ, не без учета их особенностей. И, соответственно, все это надо прямо оговорить в условиях тестирования. Можно сравнивать даже результаты заметно различающихся по конфигурации систем — если нет другого выхода. Основной смысл, собственно, как раз в сравнении, которое тем точнее, чем тестовые условия ближе, но определенный смысл имеет и тогда, когда это не получается (что особенно часто встречается в компактных высокоинтегрированных системах, «выдрать» из которых процессор и переставить его в другую платформу просто невозможно). И все же мы продолжим называть подобные тестирования «процессорными» (не забывая о нюансах) — ведь никаких других «тестирований процессоров» на данный момент нет и быть не может.
Конфигурация тестовых стендов
Как уже было сказано выше, этот вопрос важен, поскольку тем или иным образом может повлиять на результаты, с чем можно бороться, стараясь сделать окружение как можно более одинаковым. Для тестирования готовых систем это не всегда возможно, но для «настольных» процессоров — не так уж и сложно.
Для начала, операционная система и тестовые приложения жестко определены нашей методикой тестирования, даже если системы разные, не говоря уже о платформах одинакового назначения. О приложениях и их версиях мы поговорим чуть позже, а работать в рамках текущей методики они будут под управлением Windows 10 версии 1909 с всеми обновлениями на 1 декабря 2019 года. Одно это уже может изменить результаты по сравнению с предыдущими сборками «десятки» или устаревшими версиями ОС типа Windows 7/8.1 (с которыми, впрочем, мы все равно несколько лет как не работаем — хотя на компьютерах многих пользователей они все еще в строю), благодаря улучшенным оптимизациям под многоядерные процессоры (коих ныне в продаже большинство). Кроме того, планировщик Windows 10 версии 1909 уже «понимает» особенности новых турбо-режимов AMD и Intel, типа «предпочтительных» (т. е. способных работать на максимальных частотах) ядер. Возможно, в будущем Microsoft еще что-нибудь улучшит, но с новыми оптимизациями мы познакомимся только при обновлении методики, поскольку для сопоставимости результатов приходится фиксировать и версию (а также конкретную сборку) системы.
Системный накопитель мы также можем жестко зафиксировать. Как и ранее, мы пока используем твердотельный накопитель с SATA-интерфейсом: на данный момент это наиболее массовые и универсальные решения. Конкретно взят Silicon Power Velox V85 480 ГБ на базе контроллера Phison S10 и MLC-памяти Toshiba. Модель уже далеко не новая, однако по скоростным характеристикам (а главное — их стабильности) она не уступает современным устройствам среднего класса. Впрочем, предыдущие исследования показали, что более быстрый SSD может немного увеличить общую производительность системы, а винчестер — снизить ее (и иногда заметно). Как дела обстоят сейчас — проверим. Конечно, гибкости при изучении готовых систем у нас нет — их придется тестировать «как есть». Поэтому иногда будут использоваться и другие накопители —, но это всегда будет оговариваться особо. При стандартных же наших тестированиях «процессоров» будет применяться один и тот же системный SSD, причем «жестко упирающиеся» в накопитель тесты участвовать в оценке общей производительности не будут (а вот энергопотребление во время их исполнения мы учитывать будем).
Что касается оперативной памяти, то мы решили сохранить старый подход: 8 ГБ на канал, т. е. 16 ГБ для процессоров с двухканальным контроллером памяти и 32 ГБ — при наличии четырехканального. На самом деле все наши тесты «нормально чувствуют себя» и на 8 ГБ памяти — мы их специально сделали такими. Это не значит, что мы считаем такой объем памяти абсолютно достаточным на практике для всех используемых программ — на самом деле нет. Во многих из них требования к емкости ОЗУ существенным образом зависят от количества обрабатываемых данных, их типа и применяемых алгоритмов. Но это самое количество данных мы для нужд тестирования подбирали таким, чтобы время исполнения и требования к прочим ресурсам укладывались в разумные рамки. Так что в наших тестах объем оперативной памяти всегда будет «достаточным» (за исключением, возможно, некоторых компактных и/или старых систем, где придется как-то управляться с меньшим объемом памяти), а для практической работы с теми же программами… Тут всё зависит от самой работы :) В принципе, в продающихся сейчас системах меньше 8 ГБ обычно и не встречается, но и больше ставят лишь в далеко не массовые продукты. Опять же, все случаи, когда нам придется ограничиваться меньшим количеством памяти и/или отступать от формулы «один модуль памяти на канал контроллера», будут оговариваться в явной форме.
Что касается видеокарты, то с 2014-го по 2017-й мы делали основной упор на использование интегрированного видеоядра. Причин тому было несколько. Во-первых, слабое влияние GPU (в реальности, а не в бравурных отчетах производителей) на скорость работы большинства прикладных программ делало этот вопрос маловажным. Во-вторых, видеокарты постоянно дорожали: это 20 лет назад самый дорогой видеоадаптер стоил примерно столько же, сколько и самый дешевый процессор, но сейчас разброс цен между этими позициями составляет примерно 25 раз. Соответственно, для многих пользователей дискретная видеокарта стала просто нежелательным элементом компьютера: деньги тратить приходится, место занимает, электричество жрет, шумит, но ничего не дает. В итоге интегрированное видео распространялось все шире и шире, не затрагивая только геймеров. В большинстве массовых процессоров видеоядро было — и большинство массовых процессоров с ним и использовалось. Однако большинство интересных новинок последних двух-трех лет (и ожидающихся в ближайшее время) лишено интегрированной графики. В частности, у AMD все APU (так компания уже много лет называет процессоры с интегрированным GPU) пока еще ограничены двумя-четырьмя ядрами — больше есть только в процессорах без графики. HEDT-решения обеих компаний принципиально не имеют встроенного GPU. Да и в части массовых Core для LGA1151 «Second Edition» видеоядро заблокировано — для борьбы с дефицитом Intel (впервые за много лет) пришлось пойти на этот шаг.
Поэтому для тестирования настольных процессоров в подавляющем большинстве случаев мы будем использовать дискретную видеокарту на базе AMD Radeon RX Vega 56. В том числе — и в «базовых тестах» бюджетных процессоров, но их регулярно будем изучать и совместно с более дешевыми видеоадаптерами, а также с интегрированной графикой (что для разнообразных Athlon/Celeron/Pentium, разумеется, как раз самый частый случай). «Небюджетные» процессоры мы тоже будем иногда «спаривать» с другими видеоадаптерами, но поскольку производительность многих программ ныне зависит и от видеокарты, а не только от процессора, их мы в обязательном порядке будем стараться тестировать и с AMD Radeon RX Vega 56 — просто для унификации и для более корректного сравнения «процессорных составляющих».
iXBT Application Benchmark 2020
Наиболее существенные изменения тестовых нагрузок произошли при разработке Методики измерения производительности iXBT.com на основе реальных приложений образца 2018 года, описание которой приведено в отдельной статье — где можно ознакомиться и с ее принципиальным устройством, и с используемыми программами, и с конкретными тестовыми сценариями. Фактически в процессе доработки изменились лишь версии ПО, их соответствие можно посмотреть в таблице ниже (названия используемых программ, как правило, являются гиперссылками на посвященные им подробные статьи):
Радикально изменилась лишь группа рендеринга, где место LuxRender занял Cinebench R20: первая программа много лет не обновлялась, зато вторая (несмотря на ее синтетическую природу) была приведена программистами Maxon в соответствие с нынешними версиями Cinema 4D. По этой причине мы и пошли на подобную замену.
В остальном можно считать, что мы используем методику 2018 года с доработками 2019 года as is. Это же касается и представления результатов: они разбиваются по группам и приводятся с нормированием относительно референсной системы. Такой подход мы практикуем уже почти 15 лет, он имеет свои плюсы и минусы и нравится не всем, но нам — скорее нравится. Желающие же ознакомиться с точными результатами всех процессоров в конкретных тестах (традиционно выраженными во времени исполнения) могут воспользоваться «бесплатным приложением» к материалам раздела в виде полной таблицы (в формате Microsoft Excel). В ближайшее время мы планируем миграцию результатов из такой формы представления в базу данных и добавление туда же точных значений энергопотребления во время каждого теста, а не только усредненных. Будет разработан интерфейс онлайн-доступа к этой базе (с возможностью вывести на экран что угодно и сравнить с чем угодно), что повысит удобство для интересующихся «сухой цифирью», а не статьями. В самих же статьях подход не изменится.
Также (как и ранее) при тестировании процессоров мы не будем использовать группу «Скорость файловых операций», поскольку в этих тестах смена процессора при сохранении окружения практически не изменяет результаты. Соответственно, в статьях не будет «Интегрального результата Storage», а в качестве общего результата будет использоваться то, что в терминах методики называется «Интегральный результат CPU». Отходить от этой практики мы будем только при тестировании готовых систем и/или в специализированных материалах, посвященных как раз накопителям.
Что же касается референсной системы, то сейчас и в ближайшей перспективе она будет такой:
| Процессор | Intel Core i5–9600K |
|---|---|
| Материнская плата | Asus Maximus X Hero |
| Чипсет | Intel Z370 Express |
| Память | 16 ГБ DDR4–2666 |
| Графическая подсистема | AMD Radeon RX Vega 56 |
| Накопитель | SSD Silicon Power Velox V85 (480 ГБ, SATA) |
| Операционная система | Windows 10 Pro 1909×64 |
Результаты тестирования данной конфигурации и будут приняты за 100 баллов в каждой группе — и в целом. Все остальные результаты будут нормироваться относительно нее. Соответственно, интерпретация результатов проста: «больше» — всегда «лучше». 150 баллов — это в полтора раза быстрее нашей системы на Core i5–9600K с Radeon RX Vega 56, а 50 баллов — вдвое медленнее.
Энергопотребление и энергоэффективность
Несколько лет назад мы разработали технологию измерения не только затрат времени на решение каждой задачи, но и того, сколько на это уходит электроэнергии. За прошедшее время никаких проблем в используемом подходе выявлено не было, а полученные результаты не менее полезны, чем абстрактные скорости, так что мы продолжим практиковать его и дальше. Мини-ПК и подобные платформы требуют отдельного (и немного более ограниченного) подхода, но для настольных процессоров было бы неправильно не воспользоваться такими измерениями.
Методика измерения энергопотребления при тестировании процессоров iXBT.com
Что касается собственно Методики измерения энергопотребления, то она, традиционно, описана в отдельной статье. Все, что менялось за прошедшие годы — конкретный набор программ, но подход остался прежним. Сейчас же мы займемся немного другим вопросом — как весь этот набор результатов будет использоваться в статьях, посвященных тестированию процессоров.
Понятно, что получаемый массив данных слишком обширен для включения его в статьи — особенно с учетом того, что в каждой из них представлено более одного участника. Поэтому поступим мы с ним как обычно: применим методы выборки и усреднения. Из всех полученных при тестировании мощностей мы выберем максимальную и минимальную, а также среднюю по всем тестам. Эти данные, как нам кажется, имеют наибольший практический смысл, поскольку позволяют непосредственно сравнивать разные платформы. При этом основной будет не «процессорная» (т. е. измеренная по линии 12 В разъема ATX12V/EPS12V), а «общая» мощность, потому что распределение схемы питания разных блоков по линиям может быть разным. Если у Intel начиная с LGA1150 можно утверждать, что процессор питается только от «своего» разъема (ранее было не так — и не факт, что это не изменится в новых платформах), то AMD и в АМ4 практикует «забор электричества» с платы, а в системах на базе Ryzen Threadripper (и старых, и новых) основная нагрузка зачастую ложится именно на 24-контактный разъем (ATX). Кроме того, для определения требований к системе охлаждения всего компьютера (а не только процессорного кулера) надо учитывать и потребление энергии памятью или чипсетом, да и рассеивание тепла на преобразователе напряжения процессора, поскольку из корпуса надо выводить все выделенное тепло, а не только то, за которое «ответственен» процессор. В этом плане как раз очень важна максимальная мощность (не пиковая теоретическая, а усредненная по каким-то «тяжелым» задачам): столько «нагруженная» платформа и потребит/выделит, причем в реальных приложениях, а не в специально оптимизированных для максимального «прогрева» (что, кстати, не всегда достигается при максимальном энергопотреблении) стресс-тестах, еще и работающих на разных платформах с разной «эффективностью». Минимальные же значения интересны больше для сравнений разных платформ в режимах «легкой» нагрузки — опять же, не в простое (которого в современных условиях может и не быть из-за фоновой активности самой системы и интернет-приложений), а при решении практически полезных задач. Мы в качестве таковых используем «дисковые» тесты, и не сказать, что это редкий случай.
Что же касается средней мощности, причем изначально получаемой как среднее из средних, то это во многом параметр синтетический, хотя и интересный. И поскольку многих интересует не экономичность сама по себе, а в приложении к решению практических задач, мы ввели еще более синтетическую характеристику платформы — «энергоэффективность». Определяется она просто: сколько баллов нашего интегрального индекса производительности та или иная система способна выдавать в расчете на ватт потребляемой мощности (соответственно, мы просто делим итоговую производительность на среднюю по тестам мощность). Можно, конечно, усложнить подход и работать с мощностями применительно к сферам применения компьютерной системы (благо используемые нами приложения удачно разбиваются по группам), но пока мы решили не увеличивать детализацию сверх меры :) А накопленные в процессе тестирований результаты со временем позволят понять, в каком направлении лучше двигаться дальше.
Стоит учесть, что текущая версия измерительного стенда не позволяет получить полных данных при применении дискретной видеокарты, как правило использующей отдельные линии питания. С другой стороны, сравнивать мы будем стараться (как уже было сказано выше) системы одного типа, т. е. интегрированное с интегрированным, а дискретное — с дискретным, причем одинаковым. Таким образом, влиянием видеокарты в последнем случае можно будет пренебречь: одна и та же карта даст одинаковую «прибавку» всем системам, и это как раз та константа, которую можно спокойно «выносить за скобки» (как и, например, одинаковый SSD, энергопотребление которого мы тоже не измеряем — если, конечно, не говорить о спецтестированиях с участием устройств, устанавливаемых непосредственно на плату).
«Процессорную» мощность мы ранее не использовали вообще, хотя и измеряли. Причина указана выше: для многих платформ (хоть устаревшей Intel LGA1155, хоть вполне современной AMD AM4) это лишь часть потребления процессора. Поэтому и в дальнейшем мы будем использовать ее лишь изредка — только по необходимости и только в рамках сравнения устройств для одной платформы.
Методика мониторинга мощности, температуры и загрузки процессора в процессе тестирования
С модульными системами все ясно. А что делать с мини-ПК, где подключение к измерительному стенду затруднено или вовсе невозможно? Для этих целей у нас есть Методика мониторинга мощности, температуры и загрузки, в которой мы целиком и полностью полагаемся на встроенные датчики процессоров. В принципе, для процессоров Intel со времен Haswell до как минимум Coffee Lake Refresh или Cascade Lake им вполне «можно верить», что не раз показывало практическое сравнение двух методов измерений. Но продукция AMD, к сожалению, в этом случае останется «за бортом» исследования: компания добавила в Ryzen большое число датчиков, но все они традиционно показывают погоду на Марсе.
Кроме того, даже когда этот метод вообще применим, нам придется ограничиться только процессором, а не платформой, что нежелательно. Да и регулярный опрос датчиков — нежелательная фоновая нагрузка, незаметная для топовых систем, но способная сказаться на производительности каких-нибудь суррогатных процессоров. Поэтому данная методика будет применяться в основном тогда, когда другие варианты невозможны. И использовать в тестах «процессоров» мы будем только мощность: опять же, минимальную, максимальную и среднюю по тестам. Также (и тем же образом) мы будем определять «энергоэффективность» — только уже не платформы, а процессора.
…И частичное прощание с игровыми тестами
Практика использования игр для тестирования процессоров восходит еще к тем временам, когда понятия «игровой ПК» не существовало. Более того, сама по себе идея, что унылый IBM PC можно купить специально для игрового применения, казалась кому революционной, а кому и кощунственной. А игры уже были, причем постепенно становящиеся все более требовательными… к процессору, благо специализированных 3D-ускорителей еще не было. Потом те появились. Потом начали бодро дорожать — в то время как процессоры как раз сильно подешевели. Повторим: 20 лет назад самый дорогой видеоадаптер стоил примерно столько же, сколько и самый дешевый процессор, но сейчас разброс цен между этими позициями составляет примерно 25 раз — и уже не в пользу процессора. Впрочем, процессоры тоже бывают дорогими, а видеокарты — дешевыми. Но в игровом компьютере перекос всегда в одну сторону: поскольку производительность в первую очередь определяется именно видеокартой, а процессор в худшем случае может «помешать» ей (если слишком слаб), но не помочь, то вопросов, как распределять бюджет, не возникает.
Нет, можно продолжать делать вид, что ничего не изменилось — и гнать вал по плану. Например, обзавестись мощной видеокартой и использовать ее со всеми процессорами — результаты получатся не слишком осмысленными, зато красивыми и наглядными. Некоторое время мы этим занимались, но пора прекращать, поскольку изменились и сами игры. «Выход в сеть», во-первых, снял все ограничения на размеры, ранее привязанные к физическим носителям — в итоге одна современная игра может занимать столько же места, сколько целый набор приложений вместе с данными. В таких условиях делать игровые тесты частью общих как-то странно: непонятно, что на что намазано. Во-вторых же, в таких условиях просто невозможно зафиксировать версии используемых игр так же, как мы поступаем с другими программами. Последние тоже, конечно, обновляются —, но в явной форме и изредка. А в игровые приложения изменения вносятся всегда — вплоть до того, что может взять и поменяться встроенный бенчмарк (при его наличии). Плюс к тому постоянно дорабатываются видеодрайверы — в том числе, и в плане исправления ошибок работы в актуальных игровых приложениях. В совокупности это иногда делает результаты, полученные с интервалом в несколько месяцев, несопоставимыми. Да и длинный их жизненный цикл тоже перестает быть нужным. Тем более, что «горячие» новинки быстро перестают быть таковыми — и иногда еще до выхода новой («совсем новой») версии игры. Долго «живут» различные сетевые продукты — однако у них и требования сильно отличаются от «ААА»-проектов, и измерения производительности в рафинированном виде затруднены или бесполезны.
В общем, мы считаем, что в наступившем году пора сказать «Хватит!» старой практике — она себя полностью исчерпала и утратила смысл. Специальные исследования каких-либо новых проектов — да, это интересно. Изучение комфортности игрового процесса на разных бюджетных системах — тоже. А «гонять» десяток игр на разных процессорах при одинаковой видеокарте, чтобы сделать глубокомысленный вывод «у всех все нормально» — уже нет. Поэтому новую «специальную» унифицированную игровую методику мы даже разрабатывать не стали, хотя в некоторых случаях продолжим использовать Методику измерения производительности в играх iXBT.com образца 2018 года. В частности — когда нужно будет протестировать какую-либо законченную систему или интегрированный GPU каких-либо процессоров. Подобные тесты имеют смысл, раз уж до сих пор ни один процессор со встроенной графикой не справился со всем нашим набором хотя бы в минимальном качестве в Full HD.
Впрочем, пару тестов мы будем использовать и для общей процессорной линейки (с дискретной графикой): World of Tanks enCore и F1 2017. Причем в режиме «среднего» качества в Full HD: в таком виде оба теста достаточно «процессорозависимы», чтобы предоставить некоторую полезную информацию. Пусть этот вариант настроек и является синтетическим для Radeon RX Vega 56 —, но «нормальные» для сравнения процессоров вообще бесполезны: стоит повысить качество картинки и/или разрешение, как все упирается в видеокарту.
Повторимся: такой подход будет применяться ко всем процессорам регулярно. Специализированные тестирования — тема отдельная и плохо формализуемая (на то они и специализированные). В любом случае, «плясать» в игровом ПК следует от видеокарты — уже давно, и вряд ли что-то изменится в обозримой перспективе. Большинство же реально продающихся компьютеров — совсем не игровые. Собственно, хоть какая-то дискретная видеокарта встречается лишь в каждом третьем десктопе и хорошо если в одном из пяти ноутбуков. Причем эта статистика включает в себя и решения, зачастую более слабые, чем некоторые интегрированные GPU — их иногда приходится применять как затычку для слота. Ну, а без них речь будет идти лишь где-то о каждом десятом ПК — что явно непропорционально шуму, издаваемому сообществом геймеров, зато хорошо показывает настоящую актуальность игровых тестов. Так что хватит пичкать ими всех :)
Кстати, наши постоянные читатели наверняка заметили, что подобный подход к тестированию процессоров мы, в общем-то, начали практиковать уже давно — просто не декларировали его в явной форме. Настало время сделать и этот шаг.
Итого
Итак, именно таким образом мы будем тестировать настольные платформы и примкнувшие к ним решения в 2020&nb
Полный текст статьи читайте на iXBT
