Методики измерения производительности компьютерных систем в разных задачах мы, обычно, документируем достаточно подробно, а вот сам по себе процесс их использования на практике — не всегда. Однако, как выяснилось, в некоторых случаях требуются подробные разъяснения — что это и как можно воспользоваться полученными результатами. Чтобы в будущем не возвращаться к подобным вопросам, сегодня мы постараемся дать на них полные ответы. Во всяком случае, в той части, которая относится к тому, что традиционно называется «тестированием центральных процессоров». Кстати — с названия и начнем.
Как измерить то, чего не существует?
Провокационный заголовок, тем не менее, полностью раскрывающий проблему. Действительно — что такое «производительность»? Количественная характеристика скорости выполнения определенных операций. Из чего сразу же следует основной вывод — никакой «производительности процессора» не существует. В отличие от, например, производительности компьютера. Просто потому, что последний является законченным устройством, на практике способном выполнять какие-либо вычисления и все, что к ним сводится. Разумеется, многое зависит от операций, скорость которых измеряется, т.е. программного обеспечения. Которое еще и работает только под управлением определенных операционных систем, что дополнительно сужает предметную область. Однако выбрав ОС и программы, мы можем получить для аппаратной системы какой-то более или менее осмысленный результат. И даже сравнить разные системы по производительности на выбранном наборе программного обеспечения.
Но если спуститься на уровень ниже, т.е. перейти от законченных устройств к компонентам, понятие производительности очевидным образом просто исчезает, поскольку ни к какому отдельному использованию они не пригодны. Точнее, к какому-то — может быть, но не к целевому. Винчестер можно использовать как гнет при закваске капусты, а процессор — чтобы пускать круги по воде, однако их «производительность» при выполнении подобного рода «операций» никого не интересует. А та, которая интересует, может быть измерена лишь в рамках законченной системы. И, в свою очередь, будет испытывать влияние и других компонентов.
Почему же в таком случае можно все равно говорить о «производительности процессоров»? Поскольку тестовые конфигурации можно привести к более-менее одинаковому состоянию. В идеале — добиться того, что различаться они будут исключительно процессорами. Такое возможно, например, если тестируются два устройства для одной и той же платформы — будучи установленными на одну и ту же системную плату и снабжены одной и той же «периферией» (от оперативной памяти до накопителей), работать они будут со скоростью, зависящей только от них самих и/или ограниченную прочими компонентами одинаковым образом. Последняя проблема не является неразрешимой при наличии гибкости в конфигурировании — «вредные» факторы можно исключить при обнаружении. Однако и в этом случае мы измеряем не производительность процессора, а производительность всей системы.
В определенных условиях этим можно пренебречь. Например, можно утверждать, что в рамках одной платформы один процессор быстрее другого в полтора раза — если скорость выполнения набора тестовых заданий при замене одного на другой меняется в указанные полтора раза. Вот с другими характеристиками (зачастую, не менее интересными) нужно быть уже очень осторожными. Например, не имеют никакого смысла попытки считать «соотношение цена/производительность» ориентируясь только на цену процессоров. Действительно: если модель Х работает в полтора раза быстрее, чем Y, а стоит вдвое дороже, то, казалось бы, по пресловутому соотношению она заметно хуже. Но если вспомнить, что на деле мы можем получить только производительность системы, приходим к выводу, что учитывать нужно ее цену. В обязательном порядке — даже если таковая одинакова. К примеру, если Х стоит $50, Y — $100, а все остальное оборудование, которое использовалось в тестах — $450, значит увеличение производительности на 50% происходит при увеличении цены всего лишь на 10%, так что более дорогой процессор на самом деле является более выгодной покупкой. А что будет при сравнении этих же двух процессоров, когда на «окружение» потрачено $250 или $750? Строго говоря, мы не знаем. Одно тестирование в конкретных условиях не дает ответа на то, как в этом случае изменится производительность. Может выйти так, что слишком дешевая система приведет к одинаковым результатам для обоих процессоров, а на более дорогой разница увеличится (при этом разница в реальной ее цене сократится), может, наоборот (на самом деле нет), а может и ничего не изменится — недостаточно информации.
Так что, как видим, даже в рамках одной и той же платформы при возможности полностью уравнять условия тестирования все не так уж и просто, как кажется. А ведь как раз такие сравнения наименее интересны, поскольку их результаты слишком предсказуемы. Куда больше пользы от сравнения процессоров для разных платформ одного производителя (благо таковые регулярно обновляются) или вообще разных — от разных разработчиков и для разных сфер применения. В этом случае добиться одинаковых условий тестирования просто невозможно — как ни старайся. Хотя бы потому, что системные платы будут разными по-определению. Влияние их на производительность системы давно уже практически отсутствует, но только когда все идет «правильно»: мы уже сталкивались с обратными ситуациями.
В итоге, нет смысла и пытаться привести все совсем к «общему знаменателю». В некоторых случаях — и не нужно даже когда это возможно, поскольку такое «рафинированное» тестирование «в вакууме» будет слабо соотноситься с реальными условиями. Все, что требуется — постараться обеспечить сравнимые характеристики тестовых платформ, не без учета их особенностей. И, соответственно, все это прямо оговорить в условиях тестирования. Можно, даже, сравнивать результаты заметно различающихся систем — если нет другого выхода. Основной смысл, собственно, как раз в сравнении, которое тем точнее, чем тестовые условия ближе, но определенный смысл имеет и тогда, когда это не получается (что особенно часто встречается в компактных высокоинтегрированных системах, «выдрать» из которых один процессор и поставить на другую платформу просто невозможно). Но, несмотря на это, мы продолжим называть подобные тестирования «процессорными», не забывая о нюансах — просто потому, что никаких других «тестирований процессоров» на данный момент нет и быть не может.
Конфигурация тестовых стендов
Итак, как уже было сказано выше, этот вопрос важен, поскольку тем или иным образом может повлиять на результаты, с чем можно бороться, стараясь сделать окружение как можно более одинаковым. Для тестирования готовых систем это не всегда возможно, но для «настольных» процессоров не так уж сложно.
Во-первых, операционная система и тестовые приложения жестко определены нашей методикой тестирования. Всегда — даже если системы разные, не говоря уже о платформах одинаково назначения. Во-вторых, системный накопитель мы можем также жестко зафиксировать. Мы остановились на Sandisk Extreme Pro 480 ГБ по ряду причин: высокая совместимость с разными системами (благодаря использованию «обычного» SATA-интерфейса), высокая (в своем классе) производительность, достаточная для того, чтобы вместить все необходимое ПО емкость. Как показало наше исследование, разброс значений производительности при использовании разных твердотельных накопителей в текущей методике не превышает 10%, куда вполне укладывается и выбранная нами модель. Более быстрый SSD может немного увеличить общую оценку, а вот винчестер — заметно ее снизить, что следует учитывать, изучая результаты тестирования (и помнить о том, что было сказано чуть выше по поводу «цены/производительности»).
Что касается оперативной памяти, то тестовые прогоны текущей версии методики также показали достаточность 8 ГБ ОЗУ для всех используемых тестов: удвоение объема меняет результаты лишь на пару процентов даже для самых быстрых процессоров. Во всяком случае, речь идет об основной линейке тестирования — без дискретной видеокарты: таковая, как мы уже знаем, может сказаться на требованиях к объему ОЗУ, но о подобных конфигурациях разговор особый. Таким образом, столько мы и постараемся использовать во всех случаях, когда это будет возможным. И, разумеется, двухканальный режим работы памяти везде, где возможно. Если процессор снабжен одноканальным контроллером и/или тестировать приходится платформу, снабженную всего одним слотом памяти, а то и вовсе исключительно распаянными прямо на плате микросхемами — значит невозможно. Тогда придется тестировать «как получится», но, естественно, оговорив данное условие и по возможности не сравнивая полученные результаты с укомплектованными «нормальным образом» системами».
Немного особняком будут стоять тесты систем с дискретной видеокартой. Дабы не увеличивать количество работы, мы решили в основном ограничиваться одной картой, а именно Radeon R9 380X. Впрочем, какие-то разовые материалы, возможно, будут выходить и на основе тестов с другими моделями — как более медленными и дешевыми (что актуально для выбора бюджетной игровой системы), так и более производительными, и дорогими. Но в качестве «базового» для систем, интегрированной графики лишенных, а также оценки игровой перспективности некоторых «не лишенных» будет использоваться именно этот GPU. Объем же оперативной памяти во всех таковых случаях будет равен 16 ГБ. Хотя бы просто потому, что игровая система по-определению дороже «повседневной», так что большого смысла экономить на памяти в данном случае нет. Тем более, что в прошлом году мы уже сталкивались с тем, что некоторые тесты, нормально работающие на 8 ГБ памяти при использовании IGP, замедлялись при установке дискретной видеокарты — в данном случае такого объема уже попросту не хватало.
iXBT Application Benchmark 2016
Описание Методики измерения производительности iXBT.com на основе реальных приложений образца 2016 года приведено в отдельной статье, где можно ознакомиться и с ее принципиальным устройством, и с используемыми программами, и с конкретными тестовыми сценариями. Фактически ее мы будем использовать as is, что касается и представления результатов — по группам с нормированием относительно референсной системы:
Единственное, чем мы не будем увлекаться в рамках основной линейки тестирования — расчетами погрешностей измерения. Точнее, делаться они будут, но в итоговые результаты попадать не будут — дабы не усложнять сравнение разных систем (каковое и является основной целью тестирований). Ни на диаграммы, ни в «бесплатное приложение» к материалам раздела в виде полной таблицы с результатами (в формате Microsoft Excel 97-2003). Последняя может быть использована желающими ознакомиться с подробными результатами по приложениям или использовать их любым не предусмотренным в статьях образом. Собственно, для материалов раздела это было обычной практикой, одно время прекращенной, но поскольку спрос на «сырую» информацию есть, мы к ней вернулись.
Энергопотребление и энергоэффективность
Начиная с этого года, мы имеем возможность получать результаты не только производительности настольных систем, но и точно определять — сколько на их получение затрачено энергии. Мини-ПК и подобные платформы требуют отдельного (и немного более ограниченного) подхода, но вот для настольных процессоров все складывается более удачно, так что было бы неправильным этим не воспользоваться.
Что касается собственно Методики измерения энергопотребления, то она, традиционно, описана в отдельной статье. Сейчас же мы займемся немного другим вопросом, а именно тем, как весь этот набор результатов будет использоваться в статьях, посвященных тестированию процессоров.
Понятно, что получаемый массив данных слишком обширен для включения его в статьи — особенно с учетом того, что в каждой из них представлено более одного участника. Поэтому поступим мы с ним как обычно — методами выборки и усреднения. Из всех полученных при тестировании мощностей, мы выберем максимальную и минимальную, а также среднюю по всем тестам. Эти данные, как нам кажется, имеют наибольший практический смысл, поскольку позволяют непосредственно сравнивать разные платформы. А для этого мы будем брать не «процессорную» (т.е. измеренную по линии 12 В разъема EPS12V), а «общую» мощность. Во-первых, потому, что некоторые системы и на данный момент «питаются» лишь от одного разъема — Bay Trail и Braswell, например. Во-вторых, потому, что и в остальных распределение схемы питания разных блоков по линиям может быть разным. Кроме того, для определения требований к системе охлаждения всего компьютера (а не процессорного кулера) актуально и потребление энергии со стороны памяти или чипсета, да и собственно потери на MOSFET: все равно из корпуса надо выводить все полученное тепло, а не только то, что приходится на долю процессора. В этом плане как раз очень важна максимальная мощность (не пиковая, а усредненная по каким-то «тяжелым» задачам) — столько «нагруженная» платформа и потребит/выделит. Причем в реальных приложениях, а не в специально оптимизированных для максимального «прогрева» (что, кстати, не всегда достигается при максимальном энергопотреблении) стресс-тестах. Минимальные же значения интересны больше для сравнений разных платформ в режимах «легкой» нагрузки — опять же, не простоя, а при решении практически полезных задач.
Что же касается средней мощности, причем изначально получаемой как среднее из средних, то это, во многом, параметр синтетичный, хотя и интересный. Но, поскольку многих интересует не экономичность сама по себе, а в приложении к решению практических задач, мы ввели еще более синтетическую характеристику платформы — «энергоэффективность». Определяется он просто: сколько баллов нашего интегрального индекса производительности та или иная система способна выдавать в расчете на Ватт потребляемой мощности (соответственно, мы просто делим итоговую производительность на среднюю по тестам мощность). Можно, конечно, усложнить подход и работать с мощностями применительно к сферам применения компьютерной системы (благо используемые нами приложения удачно разбиваются по группам), но для первых опытов мы решили не увеличивать детализацию сверх меры :) А вот накопленные в процессе тестирований результаты уже позволят со временем понять — в каком направлении лучше двигаться дальше.
Стоит учесть, что текущая версия измерительного стенда не позволяет получить полных данных при использовании дискретной видеокарты, как правило использующей отдельные линии питания. С другой стороны, вклад последних в производительность программ общего назначения пока еще невелик, да и сравнивать мы будем стараться (как уже было сказано выше) системы одного типа, т.е. интегрированное с интегрированным, а дискретное — с дискретным, причем одинаковым. Таким образом, влиянием видеокарты в последнем случае можно будет пренебречь: одна и та же карта даст одинаковую «прибавку» всем системам, т.е. это как раз та константа, которую можно спокойно «выносить за скобки» (как, например, одинаковый SSD, энергопотребление которого мы тоже не измеряем).
С модульными системами все ясно. А что делать с мини-ПК и подобными, где подключение к измерительному стенду затруднено или вовсе невозможно? Для этих целей у нас есть Методика мониторинга мощности, температуры и загрузки, в которой мы целиком и полностью полагаемся на встроенные датчики процессоров. В принципе, для процессоров Intel со времен Haswell им вполне «можно верить», что и наше практическое сравнение двух методов измерений показало, но для других систем степень применимости данной методики — вопрос открытый. Кроме того, в данном случае нам придется ограничиться только процессором, но не платформой, что нежелательно. Да и регулярный опрос датчиков — нежелательная фоновая нагрузка, незаметная для топовых систем, но способная сказаться на производительности каких-нибудь суррогатных процессоров. Поэтому данная методика будет применяться в основном тогда, когда другие варианты невозможны. И использовать в тестах «процессоров» мы будем только мощность. Как выше — минимальную, максимальную и среднюю по тестам. Введя также (и тем же образом) в параметры «энергоэффективность», но уже не платформы, а процессора.
Небольшое замечание по поводу дополнительных нагрузок при измерении. Как показали наши первые тесты, на данный момент обе методики в целом демонстрируют согласованные результаты, да и их влияние на производительность если и есть, то в рамках погрешности ее измерения. Однако пока еще мы провели слишком мало испытаний для того, чтобы быть уверенными в сохранении данной тенденции. Поэтому (во избежание эксцессов) в этом году измерения производительности и энергопотребления будут проводиться отдельно друг от друга. Такая перестраховка приводит к увеличенным затратам времени, но пока мы склонны считать ее вполне оправданной. А дальше — посмотрим по мере накопления результатов.
iXBT Game Benchmark 2016
Методика измерения производительности в играх как обычно подробно описана в отдельной статье. Единственное изменение, которое мы решили ввести в этом году — использование двух различных тестов в игре Grid 2, что позволит измерять в ней производительность и на процессорах без поддержки набора инструкций AVX. Для которых, собственно, это уже достаточно простая с точки зрения современности игра как раз и наиболее актуальна :) Других изменений нет, так что здесь мы поговорим лишь о способах применения указанной методики, а также упрощениях и усложнениях сравнительно с «базой».
Итак, для чего нам нужны тестирования в играх? Строго говоря, в двух случаях — для измерения производительности игровых систем и для сравнения друг с другом всех остальных с точки зрения видеочасти. Начнем с первого, благо с ним проще.
Что такое «игровая система»? Несмотря на прогресс в области интеграции, это по-прежнему компьютер с обязательным наличием дискретной видеокарты. Более того — хорошей дискретной видеокарты. Впрочем, финансовые ограничения приводят к созданию и неплохим продажам «бюджетных игровых компьютеров», где используются видеокарты ценой до $150 в паре с соответствующими (по цене) процессорами начального уровня, благо и подобные все равно позволяют играть с большим комфортом, чем допускает современная интегрированная графика, но это тема отдельная и серьезного геймера не интересующая. Ну а поскольку такие варианты в основном интересны лишь для сравнения с компьютерами вовсе без дискретной видеокарты, тестировать их нужно также, как последние.
Совсем не то «приличная» игровая система. В частности, выбранная нами видеокарта Radeon R9 380X способна справиться со всеми входящими в тестовый набор играми при максимальных настройках — собственно, потому и выбрана. Во всяком случае, это верно для связки с «приличным» процессором и разрешения FullHD, но именно последнее и наиболее интересно на данный момент пользователям. Впрочем, некоторые до сих пор пользуются старыми мониторами, так что их требования к системе пониже. Кроме того, снижение нагрузки на видеокарту позволяет более рельефно высветить разницу между процессорами и платформами (когда она есть). Таким образом, мы приходим к оправданности тестирования в двух разрешениях (1920×1080 и 1366×768) при максимальных настройках качества.
А что делать с тестами основной линейки, которые, напомним, будут выполняться только с интегрированными в процессор графическими адаптерами? В данном случае основной целью тестирования является непосредственно их сравнение друг с другом — ничего лучшего, чем игры, для тестирования 3D-производительности не придумано. Тем более что такие результаты все равно имеют практический смыл: понятно, что покупать для игр компьютер без дискретной видеокарты смысла по-прежнему не имеет, но так уж устроен человек, что если уж захочет поиграть, будет это делать на том, что есть под рукой. Отдавая себе, разумеется, отчет в том, что «современные хиты», равно как и качественные настройки в данном случае недоступны, но... Нужда заставит — и не так раскорячишься (с). В конце-концов, производители процессоров давно уже (и нередко) акцентируют внимание на том, что вот теперь-то на наших встроенных решениях и игры как-то работают, так что проверить эти заявления как минимум не лишне. Только в данном случае, естественно, речь может идти только о минимальных настройках. Которые мы и будем использоваться все в тех же двух разрешениях — 1920×1080 и 1366×768.
Поскольку же далеко не все системы могут справиться с какими-либо играми даже в таком виде, во избежание загромождения статей бессмысленными диаграммами мы приняли также волюнтаристское решение: если с игрой ни в одном из двух режимах не сумел справиться ни один из героев сравнительного тестирования, эта игра из соответствующей статьи выбывает. Во всяком случае, в явном виде — а вот в неявном будет присутствовать. Что понимается под «справился»? Критерии этого субъективны — кто-то заявляет, что ему и 20 кадров в секунду хватает (лишь бы стабильных), а кто-то менее чем на 50 не согласен. Соответственно мы (как и ранее) будем считать «границей играбельности» 30 кадров в секунду. А чтоб можно было, не изучая кучу диаграмм, грубо сравнить разные системы (в т.ч. и из разных статей) на базе этого критерия мы также начиная с этого года вводим «Интегральный игровой результат». Выводиться он будет просто: если система демонстрирует результат выше 30 FPS при разрешении 1366×768, она получает один балл, а за то же самое в разрешении 1920×1080 два балла. Таким образом, учитывая, что игр у нас 13, максимальной оценкой может быть 39 баллов — это не значит, что система является игровой, но она, по крайней мере, справляется со 100% наших игровых тестов. Именно по максимальному результату мы будем нормировать и все остальные: баллы подсчитали, на 100 умножили, на 39 поделили — это и будет «Интегральный игровой результат». Для действительно игровых систем он не нужен, поскольку там уже всех больше интересуют нюансы, а для оценки «универсальных» — вполне. Получилось больше 50 — значит во что-то можно играть иногда более-менее комфортно, порядка 30 — не поможет даже снижение разрешения, ну а если 10-20 баллов (не говоря уже о нуле), то об играх с мало-мальски присутствующей 3D-графикой лучше даже не заикаться.
Итого
Итак, именно таким образом мы будем тестировать настольные платформы и примкнувшие к ним решения в 2016 году. Возможно также, что и в начале 2017: смена версий методик не всегда совпадает со сменой календарных лет. В принципе, несложно заметить, что принципиальных изменений по сравнению с предыдущими годами тоже немного — существенным добавлением являются лишь тесты энергопотребления, ввести которые давно просили некоторые из наших читателей. В остальном же тестовые методики являются согласованными друг с другом, а один и тот же референсный уровень при желании позволит сравнивать и результаты разных лет (разумеется, приблизительно и осторожно), что особенно актуально для тех решений, повторные тестирования которых проводиться не будут. Поэтому в ближайшее время мы планируем не только тестировать новинки рынка, но и обеспечить достаточное количество «опорных точек» для интересующихся сопоставимостью результатов разных методик. Тем более, подробные результаты прошлых лет уже были опубликованы, а новые (постоянно обновляемые) будут доступны изначально, что позволит желающим иногда сравнивать не только процессоры, но и разные версии программного обеспечения: во всяком случае, тогда, когда собственно тестовые задания не изменялись.
