Оригинал материала: https://3dnews.ru/221093

Ботозависимость, или зачем 3D-играм мощный CPU

Стр.1 - Постановка задачи. Первые результаты.

Предисловие. Постановка вопроса.

Разговоры от том, что важнее для комфорта в 3D-играх – мощный центральный процессор или топовая видеокарта, не утихают с момента появления первых 3D-ускорителей. Конечно, в идеале хотелось бы одновременно иметь и самый производительный центральный процессор, и самую мощную видеосистему. Однако ограниченность ресурсов для покупки компьютера топовой конфигурации, а тем более скачкообразное развитие технологий CPU и GPU, оставляют массу вопросов в выборе оптимального сочетания этих двух самых важных составляющих современного компьютера. Одни настаивают на необходимости использования мощной видеосистемы, другие говорят, что без мощного CPU тоже не обойтись. Правы и те, и другие. Дело в том, что какие-то 3D-приложения более чувствительны к производительности видеосистемы, а какие-то – к мощности центрального процессора. Если же в вышеупомянутом «споре» не указывать детально, к какому именно случаю относится приводимый пример, то этот спор рискует затянуться до бесконечности. Это как спорить о том, что лучше – яблоки или апельсины? Первоначально, поводом написания этой статьи послужило желание определить ту минимальную грань производительности центрального процессора, которой было бы достаточно для комфортной игры в настоящий момент. Нечто подобное, отчасти, мы уже видели, когда сравнивали производительность современных AGP-видеокарт на разных платформах. Как показало то тестирование, в условиях ограниченной производительности видеосистемы мощность центрального процессора (и всей платформы в целом) не имеет решающего значения. Отсюда и возникла мысль - а что если взять достаточно мощную видеокарту и, варьируя мощность CPU, посмотреть, как будет меняться FPS в этом случае. Собственно, этому вопросу и посвящено наше сегодняшнее исследование. К сожалению, в рамках одной статьи невозможно сравнить между собой все имеющие на данный момент платформы, поэтому мы решили остановиться на двух из них - Intel Core 2 Duo и Athlon 64 X2. Однако даже с использованием только этих двух платформ можно получить весьма интересные результаты.

Условия тестирования

Первая платформа это наш стандартный стенд:

Тестовый стенд №1
Шина
PCI-Express
CPU
MB
Memory
OS
WinXP + SP2 + DirectX 9.0c
PSU
Thermaltake ToughPower 750 Wt
Помимо тестирования на частоте 2,93 ГГц, мы также проводили тестирование на частоте CPU равной 1,87 ГГц. Это было достигнуто понижением множителя CPU с 11 до 8. В идеале, для получения полной картины процессорозависимости, следовало бы провести тесты при каждом значении множителя CPU, но это довольно трудоемкая задача. В то же время, для оценки масштабируемости результатов FPS в зависимости от частоты CPU, нам будет вполне достаточно двух указанных частот. Вторая платформа выглядит следующим образом:

Тестовый стенд №2
Шина
PCI-Express
CPU
MB
Memory
OS
WinXP + SP2 + DirectX 9.0c
PSU
FSP 400 Wt
Помимо центрального процессора, другим существенным отличием второй платформы является использование оперативной памяти стандарта DDR-I. На первый взгляд, тестовые платформы находятся в сильно неравных условиях. Тем не менее, применение памяти стандарта DDR-I не особенно критично в 3D-приложениях, поскольку здесь не так важна абсолютная пропускная способность шины памяти, сколько малые тайминги и латентность оперативной памяти (DDR-I в этом смысле предпочтительнее DDR-II). С другой стороны, как вы далее увидите, мы постарались сделать так, чтобы вообще максимально снизить нагрузку на оперативную память. Как и в случае с платформой Intel Core 2 Duo, для Athlon 64 X2 мы использовали две частоты CPU. Первая частота указана в описании стенда и равна 2,70 ГГц (к сожалению, разгон до более высоких частот приводил к нестабильности системы), вторая частота равна 1,89 ГГц и достигнута понижением множителя CPU с 10 до 7. Как видите, вторые, более низкие частоты для выбранных нами платформ очень близки друг к другу, поэтому мы можем сравнить эффективность центральных процессоров от Intel и AMD при практически равных условиях. В качестве видеосистемы мы использовали видеокарту Radeon X1900XTX. По нынешним меркам это не самое топовое решение, однако вполне достаточное для наших целей. Ну а теперь расскажем о ключевых особенностях тестирования. Тестирование проводилось с помощью драйверов Catalyst 7.2. Мы будем изучать зависимость значений FPS от степени загрузки CPU на примере игры “Counter Strike: Source”. Как вы знаете, игра использует движок Half-Life 2 и по меркам компьютерного мира уже является довольно старой. Но в этом тестировании нам и не нужна неимоверно тяжелая графика. А вот то, что игра демонстрирует довольно достоверную физику и «боты» обладают довольно продвинутым интеллектом, нам очень даже пригодится. Согласно показаниям «диспетчера задач», при запуске игры загрузка CPU на наших тестовых стендах составляла 50%, а это значит, что игра не оптимизирована для работы с многоядерными процессорами. Таким образом, «чистота» эксперимента только возрастает, поскольку системные службы Windows выполняются на одном ядре, а второе ядро целиком отводится под игру. Видеорежим, в котором мы тестировали:
 source-settings2.jpg
 source-settings1.jpg
Мы специально взяли разрешение 1280х1024 и максимальные установки качества изображения в игре. Это позволит загрузить видеокарту, чтобы получить горизонтальную «полочку», которая показывает, что уровень FPS ограничен производительностью видеосистемы. Но, в то же время, уровень этой «полочки» будет находиться достаточно «высоко», чтобы не скрадывать уменьшение FPS при увеличении нагрузки на центральный процессор. Объяснение выглядит несколько туманно, но, поверьте, как только мы доберемся до первого же графика, все станет на свои места. Теперь несколько слов о методике тестирования. Суть тестирования состоит в том, что мы на локальном компьютере создаем мультиплеерную игру и постепенно увеличиваем количество ботов. То есть, увеличивается нагрузка на центральный процессор, поскольку именно он отвечает за расчет физики и искусственного интеллекта ботов. Изменение FPS (если такое случится) с увеличением количества ботов, как раз и покажет нам влияние загрузки CPU на средний FPS. Игра создавалась на карте de_dust, ниже вы видите скриншот в точке рождения «террористов».
 respawn-point.jpg
Средний FPS, который в этом и последующих тестах измерялся с помощью утилиты FRAPS, в этом случае находился на уровне около 110 FPS. Зависимости от платформы и частоты CPU в этом случае не наблюдалось, то есть все «упиралось» в производительность видеокарты. Как снизить влияние видеокарты? Очень просто. Ниже вы видите второй скриншот, который получен при максимальном приближении к стене.
 de_dust-test-point.jpg
В этом случае средний FPS сразу же подпрыгивал до уровня примерно 150 FPS, и опять же не зависел от типа платформы и частоты центрального процессора. Это значит, что уровень FPS опять определяется производительностью видеокарты. Ситуация выглядит несколько искусственной, но посмотрите, что нам это дает. «Отвернувшись» к стенке, мы сильно облегчили задачу видеокарты. Теперь ей не надо отображать множество объектов обстановки и ботов, которых мы будем постепенно добавлять. В этих условиях можно ожидать, что уровень FPS, зависящий только от видеокарты, будет оставаться неизменным, независимо от числа ботов. А это значит, что все изменения среднего значения FPS будут определяться только нагрузкой на центральный процессор. Таким образом, методика тестирования выглядит так – в начале каждого раунда бежим до ближайшей стены в «точке рождения», упираемся в нее «лбом» и запускаем подсчет FPS с помощью FRAPS. Подсчет идет до тех пор, пока количество ботов остается таким же, как и в начале раунда. Как только хоть один из ботов погибает - останавливаем FRAPS (чтобы не искажать картину уменьшившейся нагрузкой на CPU). Затем увеличиваем количество ботов и повторяем вышеприведенные действия. И вот что из этого получается. Мы взяли значения среднего FPS из файлов «…minmaxavg.csv» и отложили их на графике. По оси Х указано количество ботов с шагом в 2 бота (на каждом шаге добавляли по одному боту за контров и за терроров, чтобы им не скучно было). По оси Y отложены значения FPS. Линии синего цвета соответствуют платформе Intel Core 2 Duo, более светлый оттенок означает более высокую частоту CPU. Аналогично построены две линии для платформы AMD Athlon X2, но уже зеленого цвета.
 graph1.gif
График 1
Полученный график в особых комментариях не нуждается. Четко видно превосходство процессоров Intel Core 2 Duo. И спад FPS при росте числа ботов у них начинается существенно позже, и превосходство архитектуры C2D даже на равных частотах составляет порядка 1,5-2 раза по сравнению с Athlon. На этом можно было бы и остановиться, но вы же не думаете, что все это затевалось ради одного единственного графика? На самом деле, пока мы увидели только верхушку айсберга. Данные, собранные в процессе тестирования, позволяют «копнуть» гораздо глубже и получить еще массу весьма занятных сведений. Интересно? Читаем

Стр.2 - Тонкие методы. Неожиданные результаты.

Если вы внимательно изучили График 1, то наверняка задались вопросом – почему линии графика такие «кривые»? Тем более странно, что в некоторых случаях увеличение числа ботов приводит к повышению значения среднего FPS, хотя по логике вещей такого быть не должно, да и вообще, линии графика должны плавно и равномерно приближаться к оси Х по мере возрастания нагрузки на процессор. Однако такого не происходит. И вот почему. Во-первых, мы измеряем FPS с помощью FRAPS. Такой способ сам по себе содержит определенную погрешность. Во-вторых, время тестирования каждой сцены достаточно мало (15-20 секунд, а потом боты начинают убивать друг друга), это тоже вносит определенную погрешность. В-третьих, мы не знаем, как движутся и взаимодействуют друг с другом боты в каждом раунде, но можно утверждать, что разные раунды совершенно точно не идентичны друг другу. Казалось бы, как в таких условиях можно получить «приличные» результаты? Однако попробовать можно. Давайте построим еще один график, но вместо среднего FPS, как на Графике 1, возьмем минимальный FPS из того же файла FRAPS с именем «…minmaxavg.csv». Смотрите, что получится.
 graph2.gif
График 2
Теперь линии графиков ведут себя гораздо ближе к теории. При увеличении числа ботов в игре минимальный FPS уже не превышает предыдущих значений и графики стремятся к оси Х более плавно. Почему так получается? Давайте вспомним определение среднего FPS – это суммарное количество кадров, отрендеренных в процессе тестирования демо-сцены, поделенное на время тестирования. То есть, средний FPS есть величина интегральная. А вот минимальный FPS величина несколько другого рода, и характеризует уровень «провалов» FPS в процессе тестирования демо-сцены. В наших условиях тестирования эти «провалы» обусловлены не видеокартой, поскольку она совсем не нагружается, а загрузкой центрального процессора. Увеличивая число ботов, мы нагружаем CPU, то есть на просчет каждого кадра требуется все больше и больше времени. Таким образом, минимальный FPS как величина, обратная времени, должен уменьшаться. Именно это мы и видим на графиках. Продолжим. Для дальнейшего изложения мы воспользуемся методами, указанными в статье «Методика тестирования видеокарт 2007. Использование FRAPS». Сейчас мы продемонстрируем, как «разделяются» FPS на два типа – те, которые зависят от GPU, и те, которые зависят от CPU. Звучит ненаучно и совершенно фантастично, но это так. Давайте возьмем платформу Core 2 Duo @ 2,93 ГГц и построим диаграммы распределения FPS для разного числа ботов. Итак.
 graph3.gif
График 3
Когда число ботов равно нулю, а главный герой стоит лицом к стенке, мы видим один колокол распределения, причем весьма узкий. Так и должно быть. Поскольку ничего не происходит, видеокарта рисует столько кадров сколько может, с незначительными флюктуациями вокруг среднего значения равного 151 FPS. Увеличим число ботов до 10 штук.
 graph4.gif
График 4
Как видите, при увеличении числа ботов главный пик остается практически на том же месте, но колокол «размазывается» по оси Х. Как видно из Графика 2, заметное проседание минимального FPS на платформе Core 2 Duo @ 2,93 ГГц начинается с 14 ботов (в наших условиях тестирования). Давайте возьмем 16 ботов, так сказать – с запасом, и посмотрим на диаграмму распределения FPS.
 graph5.gif
График 5
И опять получаем главный пик на уровне 150 FPS и размазанный по оси Х спектр. Но что это, левая часть спектра отделилась от основной массы и образует отдельный «колокол»! Смею утверждать, что этот левый колокол как раз и образован из значений FPS, зависящих от производительности центрального процессора. Если предположение верно, то при увеличении нагрузки на CPU (добавлении ботов), «колокол CPU» будет смещаться влево по оси Х. Давайте проверим. Возьмем 24 бота.
 graph6.gif
График 6
Как видите, «колокол CPU» действительно смещается влево. Если взять 30 ботов и более, то такое «движение» станет еще более очевидным.
 graph7.gif
График 7
 graph8.gif
График 8
Помимо смещения влево колокола, образуемого «процессорными» FPS, на этих диаграммах прослеживается еще одна очень интересная тенденция. Во-первых, увеличивается расстояние между левой и правой частями распределения FPS, впрочем, так и должно быть. Во-вторых, правая часть распределения также несколько смещается влево. В-третьих, по мере роста нагрузки на CPU, количество FPS в правой части распределения значительно уменьшается по сравнению с количеством значений в левом «колоколе». О чем это говорит? Скорее всего, о том, что CPU настолько «поглощен работой», что не в состоянии выдать видеокарте требуемое количество «каркасов для раскраски». Подчеркнем, что такая картина распределения справедлива для всех платформ. Возможна ли такая ситуация, когда CPU будет загружен настолько, что второй (правый) колокол просто исчезнет? Возможна. И это можно продемонстрировать, если мы увеличим количество ботов для этой платформы или… возьмем другую платформу, «послабее». Давайте возьмем ту же платформу на базе Intel Core 2 Duo, но с частотой центрального процессора не 2,93 ГГц, а 1,87 ГГц. Ниже приведена диаграмма распределения FPS при количестве ботов 30 штук.
 graph9.gif
График 9
А далее приведем диаграмму для этой же платформы Intel Core 2 Duo @ 1,87 ГГц, но уже с числом ботов равным 32 штуки.
 graph10.gif
График 10
Как видите, правый колокол распределения исчез. Центральный процессор уже не позволяет продемонстрировать всю свою мощь видеокарте, которая при этом совершенно не нагружена. Означает ли это что, выражаясь разговорным языком, процессор «не тянет» видеокарту? В принципе, можно сказать и так. Но с другой стороны, с этой же видеокартой этот же самый процессор 30 ботов, выходит, тянет? На самом деле, видеокарта здесь не при чем. В данных условиях центральный процессор «не тянет» возложенную на него нагрузку, и какая бы видеокарта не присутствовала в системе, результат отличался бы не сильно (если, конечно, видеокарта не полный low-end). Теперь можно сформулировать граничный критерий недостаточной мощности CPU. Если в заданных условиях (игры или тестирования) нагрузка на видеокарту минимальна, а на диаграмме распределения FPS правый колокол распределения «исчезает», то производительность центрального процессора – недостаточна. И еще одно важное практическое следствие, обусловленное «исчезанием» правого колокола распределения. В этот момент должно наблюдаться резкое падение среднего FPS. И вот почему. Пока присутствуют оба колокола распределения, очевидно, средний FPS будет находиться между ними. Если же правый колокол исчезает, то средний FPS будет находиться примерно посередине оставшегося левого колокола. Если мы вычислим средний FPS на основе мгновенных FPS из Графиков 9 и 10, то получим, что для Графика 9 средний FPS будет равен 68, а для Графика 10 – всего 23. Как видите – трехкратный скачок в показываемой производительности при добавлении всего лишь двух «лишних» ботов, при этом от видеокарты совершенно ничего не зависит.

Заключение

Нет никаких сомнений, что данный материал вызовет неоднозначную реакцию читателей и оставит очень противоречивые впечатления. Да, по сути, это частный случай тестирования одной единственной игры. Да, условия тестирования также выглядят нереально «синтетическими» (где это видано – «играть в игру, стоя лицом к стенке»). Да, измерение FPS утилитой FRAPS вносит приличную погрешность, особенно на коротких интервалах времени и при неидентичных демо-сценах. Критерий, который был сформулирован в конце статьи, тоже достаточно трудно использовать на практике. Все это так. Тем не менее, не претендуя на микронную точность количественных измерений, мы получили весьма интересные качественные результаты о «вкладе» центрального процессора в общую производительность системы. Конечно, много вопросов осталось открытыми, но мы надеемся, что данное исследование все же будет вам интересно или, по крайней мере, даст пищу для размышлений. Обсудить на форуме



Оригинал материала: https://3dnews.ru/221093