Процессорозависимость видеосистемы

С момента опубликования статьи «Процессорозависимость видеосистемы. Часть I - Анализ» мы получили много откликов от вас, уважаемые читатели. Наряду с вопросами, когда же выйдет вторая часть материала, также было много замечаний относительно приведенных графиков и сомнений относительно их достоверности в некоторых специфических случаях.

Сегодня мы дадим объяснение нескольким нюансам, которые вызвали живой интерес у публики, но не были подробно описаны в первой части. Рассмотрим влияние объема кэш-памяти центрального процессора и скорости работы оперативной памяти на производительность в 3D-играх. А также вплотную подойдем к вопросу сравнения платформ в целом. Итак, начнем.

«Нестыковка» №1. Или - куда подевался «ноль»

Обратите внимание на график, приведенный ниже.

Этот график взят нами из первой части статьи. Мы видим, что линии, отражающие производительность видеокарты в разных режимах, при уменьшении частоты центрального процессора сходятся к одной и той же наклонной линии. «Нестыковка» состоит в том, что если мы попытаемся продлить эту аппроксимирующую линию до пересечения с осью “FPS”, то увидим, что прямая приходит не в начало координат, а несколько выше. Получается, что при нулевой частоте центрального процессора мы можем играть, причем со скоростью целых 15 кадров в секунду?!

Как такое может быть? Если отвлечься от условий тестирования, в которых мы получали результаты, то теоретически такая ситуация все-таки возможна. Допустим, мы загрузим в память видеокарты некоторые данные вместе с шейдерными программами, которые должен выполнять видеочип, и пусть себе все автономно крутится, центральный процессор тут не нужен. Примеры использования видеопроцессоров для математических расчетов известны. Но в наших условия тестирования такой результат получить физически невозможно. Кто-то же должен рассчитывать положение объектов в игровой сцене вместо CPU! Как же на самом деле должен вести себя график процессорозависимости, при стремлении частоты центрального процессора к нулю?

Попытка провести эксперимент на реальном оборудовании осложняется тем, что более низкие значения множителя CPU уже недоступны, а если просто взять какой-то "совсем слабый процессор» - мы изменим платформу, то есть условия тестирования, как следствие, корректно сопоставить результаты тестирования уже не получится. Что же делать?

Давайте попробуем предсказать «поведение» кривой процессорозависимости с помощью логики и реального «поведения» типичного персонального компьютера. Для этого нам придется несколько углубиться в принципы работы операционных систем с вытесняющей многозадачностью. Не пугайтесь этого длинного термина. Скорее всего, для работы и игр вы используете именно такую операционную систему. Ведь речь идет о хорошо всем известной операционной системе - Windows XP. Помимо Windows XP к операционным системам с вытесняющей многозадачностью относятся и Windows2000, и все клоны Linux. Особенность этих операционок, существенная для нашего рассмотрения, состоит в том, как они распоряжаются ресурсами «железа», а именно - распределение процессорного времени для одновременного выполнения нескольких задач. Нам, сидя за персональным компьютером, кажется, что все выполняется одновременно - и закачка файлов из Интернет, и воспроизведение музыки, и запись CD-диска, однако в реальности все выглядит несколько по-другому. Все приложения, которые вы запустили на своем компьютере, выполняются в строгой последовательности! Никакого противоречия здесь нет. Поскольку процессор один, то все приложения выполняются по очереди, по «кусочкам». Но эти кусочки настолько малы, а операционная система настолько быстро между ними переключается, что человек не в состоянии это заметить, и возникает иллюзия, что все выполняется одновременно. Если говорить кратко и упрощенно, то все время работы центрального процессора разбивается на некоторые промежутки, или «кванты» времени. А затем эти «кванты» времени «выдаются» приложениям, типа - нате поработайте, вот вам процессор на пару миллисекунд. При этом ядро многозадачной операционной системы и само потребляет некоторую часть этих «квантов» времени процессора, для того чтобы работали системные службы, да и просто - надо же операционке «подумать», какому приложению отдать следующий «квант». То есть, появляются некоторые «непроизводительные» (с точки зрения пользовательского приложения) потери времени процессора, которые идут на обслуживание собственно операционной системы.

Все вышеизложенное имеет самое непосредственное отношение к нашей «нестыковке». И вот почему. Если операционная система для обеспечения своей работоспособности требует некоторого фиксированного количества «квантов» времени центрального процессора, то очевидно, что при уменьшении частоты CPU количество свободных «квантов», которые могут быть выделены для работы приложения (в нашем случае 3D-игры), будет уменьшаться быстрее, чем частота процессора. Можно это выразить и другими словами. Предположим, что при частоте процессора в 100 МГц его производительности хватит для обслуживания только операционной системы. Тогда для получения эквивалентной частоты CPU, то есть количества «мегагерц», которые доступны приложению, мы должны из реальной частоты процессора вычесть эти самые 100 МГц, отводимые для операционной системы. В этом случае получается, что при частоте CPU 1000 МГц величина «поправки на операционку» составляет 10%, при частоте CPU в 200 МГц - уже 50%, а при частоте CPU 100 МГц - мы получим 0 FPS. На следующем графике мы проиллюстрировали все сказанное выше.

Красной прерывистой линией обозначено предполагаемое поведение кривой процессорозависимости при стремлении частоты CPU к нулю. Внимание - эта линия проведена произвольно и не является отображением каких-либо экспериментальных данных!

Вам может показаться странным, зачем мы уделяем этому вопросу столько внимания и времени. Ведь процессоры со столь низкими частотами уже практически не используются в персональных компьютерах, да и практической пользы от эксперимента, даже если его удалось бы выполнить - на первый взгляд нет. Все так, но и не совсем так.

Давайте зададимся вопросом - «а как можно исключить или минимизировать влияние операционной системы на скорость работы приложения?». То есть - возможно ли вообще получить график процессорозависимости, проходящий через начало координат? Забегая вперед, скажем - возможно, если операционная система будет выполняться… на другом процессоре. Но к этому вопросу мы вернемся чуть позже.

Нестыковка №2. Нелинейность «линии максимально возможных результатов»

Только что мы рассмотрели поведение «линии максимально возможных результатов» при уменьшении частоты CPU. Теперь давайте посмотрим, что происходит, если мы пойдем в другую сторону и будем увеличивать частоту CPU.

Собственно, суть «нестыковки» хорошо заметна на все том же графике, который мы рассматривали выше. А именно - в какой бы точке «линии максимально возможных результатов» мы не строили касательную, при увеличении частоты CPU дальнейшие результаты отклоняются от касательной вниз. Почему график не следует линейному закону, а начинает «пригибаться» к оси Х? Приведем несколько причин, объясняющих данное явление.

Первая причина - расход мощности центрального процессора на нужды операционной системы. Вопрос, который выше уже рассматривался.

Вторая причина - влияние множителя CPU. Спрашивается, при чем тут коэффициент умножения CPU? А притом, что если увеличивать скорость процессора только за счет множителя, мы вроде бы увеличиваем мощность CPU по обработке данных, но ведь их еще надо ядру CPU доставить, а скорость процессорной шины остается неизменной. Для задач с большим количеством данных, которые надо обрабатывать и которые не помещаются в кэш-память процессора, может возникнуть момент, когда ядро CPU уже обсчитало имеющиеся данные, и ждет подкачки следующей порции. То есть, процессор начинает простаивать, что можно рассматривать как снижение «эффективной» частоты работы CPU.

Третья возможная причина - характер распределения процессорного времени между графическим драйвером (который выполняется на CPU) и собственно расчетами игры (также выполняемыми на CPU). Ситуация выглядит несколько запутанно, поскольку обе задачи используют центральный процессор, да и графический драйвер можно отнести как к компоненту операционной системы (по архитектуре), так и к важному звену с точки зрения выполнения 3D-приложения.

Другие возможные причины - латентность и пропускная способность оперативной памяти, шины процессора и т.д.

Список приведенных причин не является окончательным и исчерпывающим, и при желании можно найти еще несколько факторов, из-за которых поведение «линии максимальных результатов» будет отличаться от прямолинейного. Определение степени влияния каждой из указанных причин и поиск «бутылочного горлышка» - довольно обширная тема для исследования. Прежде, чем перейти к рассмотрению частных вопросов, сформулируем общий постулат:

В многофакторной среде линейная зависимость какой-либо величины от определенного параметра может быть достигнута только при условии отсутствия ограничений со стороны всех остальных параметров.

Или же, другими словами, именно тот параметр, в зависимости от которого строится график, и должен быть наиболее ограничивающим фактором.

Применительно к нашему рассмотрению процессорозависимости видеосистемы это означает, что кроме CPU, производительность всех остальных компонентов должна быть достаточной и не создавать каких-либо ограничений. То есть - видеокарта должна быть мощная и работать в наилегчайшем из режимов (например, 640x480 вместо 1600х1200 при прочих одинаковых настройках), оперативная память должна работать с максимальной скоростью, влияние операционной системы сведено к минимуму и т.д.

Как бы там ни было, на практике, при увеличении частоты центрального процессора, мы все равно наблюдаем рост «линии максимально возможных результатов». И хотя этот рост не является строго линейным, для оценки «потолка» возможной производительности платформы в 3D-приложениях он вполне применим.

Далее мы рассмотрим несколько факторов, которые влияют на производительность компьютера в 3D-приложениях. Но речь пойдет уже о вещах, которыми мы можем в той или иной степени управлять, выбирая центральный процессор и тип оперативной памяти, то есть - выбирая «платформу» для запуска 3D-приложений.

Влияние скорости работы оперативной памяти

В первой части статьи, несмотря на всю общность поставленной задачи, мы использовали одну единственную платформу - процессор Athlon 64 4000+, материнскую плату на базе чипсета nForce 4 SLI и оперативную память DDR400, работающую в двухканальном режиме. Причем из перечисленных здесь компонентов изменялась лишь частота процессора с помощью понижения множителя, а такие параметры как частота системной шины (FSB), скорость работы памяти и все остальное оставалось неизменным. Вполне резонно прозвучит вопрос - а как же будут выглядеть графики процессозависимости при изменении других параметров? Ведь и скорость работы оперативной памяти, и объем кэш-памяти процессора влияют на производительность. Степень влияния этих параметров мы сейчас и изучим.

Условия тестирования, использованные в первой части статьи, вам известны.

Мы использовали метод нахождения «линии максимально возможных результатов», то есть, для выбранного 3D-приложения выставлялось минимально возможное разрешение без полноэкранного сглаживания (AA) и анизотропной фильтрации (AF). В этом случае результаты определяются производительностью не видеокарты, а центрального процессора, вернее даже - платформой в целом!

Помимо уже проведенных тестов стандартной конфигурации стенда с оперативной памятью DDR400 в двухканальном режиме, были получены результаты для конфигураций:

• Скорость памяти - DDR400, режим - одноканальный (Single Channel DDR400)
• Скорость памяти - DDR200, режим - двухканальный, (Dual Channel DDR200)
• Скорость памяти - DDR200, режим - одноканальный (Single Channel DDR200)

Пусть вас не смущает некоторая «искусственность» указанных режимов для оперативки. Как это ни странно, режим Single Channel DDR400 вполне можно встретить в домашних компьютерах пользователей. Причины банальны - наличие всего одной планки памяти с прицелом на «докуплю когда появятся деньги», или же неправильная установка двух модулей памяти в один канал. Режим Dual Channel DDR200 более экзотичен, но тоже иногда встречается. Когда установлено 4 модуля памяти, некоторые материнские платы автоматически понижают скорость работы оперативки до DDR333 или даже DDR266 для улучшения стабильности. Вариант понижения скорости до DDR200 является некоторым преувеличением, но мы лишь хотим проиллюстрировать, как будут меняться результаты при таких минимальных настройках. Это же касается и режима Single Channel DDR200.

Полученные результаты отображены на графике.

И какие же выводы мы можем сделать из этого графика? Как оказывается, более важный параметр - скорость работы памяти, а не число каналов! Одноканальный режим DDR400 более производителен, чем двухканальный режим DDR200, хотя максимальная теоретическая пропускная способность памяти в этих случаях одинакова. Самые низкие результаты, разумеется, показывает система с одноканальной памятью DDR200. Но что интересно, платформа с памятью DDR400 Dual Channel отличается от платформы с памятью Single Channel DDR200 по максимальной пропускной способности памяти аж в 4 раза, а вот разница в результатах (для одной и той же частоты CPU) оказывается на уровне всего лишь 50%, те есть - 1,5 раза.

Система с Dual Channel DDR200 отстает от лидера на 25%, а система с Single Channel DDR400 - всего лишь на 10%. Что касается остальных возможных типов памяти (DDR333 и DDR266), то результаты подобных систем, очевидно, будут находиться между результатами систем с памятью DDR200-DDR400.

Вот и ответ, о том, как режим работы и скорость оперативной памяти влияют на максимально возможные результаты для выбранной платформы. Мы не случайно подчеркнули данную фразу, поскольку в реальной ситуации показываемые результаты (FPS) ограничиваются, как правило, производительностью видеокарты. Предположим, что в условиях нашего тестирования некая видеокарта способна выдать максимум 60 FPS, тогда при частоте CPU, превышающей 1400 МГц, получается что для раскрытия всего потенциала видеокарты даже системы с оперативкой Single Channel DDR200 вполне достаточно!

Практический вывод для экономных пользователей - не спешите выкидывать старую память стандарта DDR266 и DDR333, ведь оперативки никогда много не бывает и она еще послужит.

Теперь перейдем к более сложному вопросу.

Влияние объема кэш-памяти CPU

Следующим объектом нашего рассмотрения, как понятно из заголовка, станет попытка оценить степень влияния объема кэш-памяти CPU на производительность платформы в 3D-приложениях. Большое количество различных тестов показывает, что в 3D-играх производительность не сильно зависит от объема кэш-памяти CPU. Сегодня мы готовы перейти от интуитивных ощущений к цифрам и привести количественную оценку степени влияния объема кэш-памяти CPU на производительность в играх.

Сложность состоит в том, что мы не можем произвольно изменять объем встроенной в ядро CPU кэш-памяти, поэтому возможным вариантом решения данной задачи представляется сравнение двух процессоров, отличающихся только объемом встроенной кэш-памяти при сохранении прочих параметров неизменными.

Наш «основной» процессор, который мы до сих пор использовали при подготовке материалов данной статьи - Athlon 64 4000+. Данный процессор имеет 128 Кб кэш-памяти первого уровня (L1-cache) и 1024 Кб кэш-памяти второго уровня (L2-cache). Для сравнения мы могли бы взять процессор Athlon 64 3800+, у которого объем кэш-памяти первого уровня такой же, а объем кэш-памяти второго уровня вдвое меньше - 512 Кб, но мы решили пойти несколько дальше.

Для примера мы рассмотрим довольно популярное в массовом сегменте семейство процессоров Sempron в исполнении Socket 754. Находящийся у нас экземпляр Sempron имеет рейтинг 3400+, штатную тактовую частоту 2000 МГц, объем встроенной кэш-памяти - 128 Кб (L1-cache) плюс 256 Кб (L2-cache). То есть, объем кэш-памяти второго уровня у выбранного нами процессора Sempron в 4 раза меньше, чем у Athlon64 4000+.

Что касается корректности эксперимента, то процессоры семейства Sempron также поддерживают технологию изменения множителя в сторону понижения, поэтому мы применим ту же методику построения графика процессорозависимости, что и в случае с Athlon 64 4000+. Отличие Sempron s754 от Athlon 64 s939 состоит в поддержке только одноканального режима памяти и уменьшенном объеме кэш-памяти процессора. Полученную «линию максимально возможных результатов» мы поместим на тот же график, где сравнивалась производительность платформ Athlon64 с различной оперативной памятью. Для платформы Sempron s754 использовалась оперативная память DDR400 Single Channel.

И что же мы видим? Результаты, показанные платформой Sempron s754 DDR400 Single Channel, практически в точности повторяют результаты Atlon64 DDR200 Dual Channel. Удивительно, но факт - процессор Sempron s754 в 3D-играх показывает достойную производительность и не так уж сильно отстает от старших собратьев.

Это все хорошо, скажете вы, но при чем тут объем кэш-памяти и как оценить его влияние на производительность платформы? Очень просто, давайте уберем из вышеприведенного графика «все лишнее» и внимательно приглядимся. На нижеследующем графике мы оставили только две линии, соответствующие платформам Sempron s754 и Athlon64 DDR400 Single Channel. Обратите внимание, что для данных платформ скорость и режим работы оперативной памяти одинаковы, и все отличие состоит только в объеме кэш-памяти процессоров.

Как видите, при четырехкратной разнице в объеме кэш-памяти второго уровня Sempron показывает результаты лишь на 10-12% хуже, чем Athlon64, работающий на той же частоте. (Замечание - результаты для Sempron начинаются с частоты 2000 МГц, поскольку это максимальная для данного процессора штатная частота, а разгон привел бы к изменению частоты работы системной шины, оперативной памяти и, как следствие - к искажению результатов). Из вышеприведенного графика также следует вывод, что для процессоров Athlon64 с объемом кэш-памяти второго уровня равным 512 Кб линия «максимально возможных результатов» будет занимать промежуточное положение, то есть разница по сравнению с Sempron будет еще меньше.

Таким образом, для процессоров архитектуры AMD K8 величина объема кэш-памяти в 3D-играх оказывает незначительное влияние на общую производительность платформы.

А что получится, если на платформу Sempron установить достаточно мощную видеокарту типа 7900GT и включить режим 1280x1024 4AA/16AF? Разрешение экрана 1280х1024 точек мы выбрали потому, что это «родное» разрешение для большинства популярных ЖК-мониторов с диагоналями 17 и 19 дюймов, ну а для большинства типовых ЭЛТ-мониторов этого же размера рекомендуемое разрешение равно соответственно 1024х768 и опять же 1280х1024 точек. Мы «утяжелили» графический режим, включив анизотропную фильтрацию и полноэкранное сглаживание, чтобы продемонстрировать - бюджетный процессор это не повод отказывать себе в графике высокого качества.

Как видно из графиков, и "линия максимальных результатов", и кривая процессорозависимости для режима 1280х1024 4AA/16AF в случае процессора Sempron лежат ниже соответствующих линий для процессора Athlon 64. Такое поведение линий вполне нормально, поскольку игра довольно старая, а видеокарта, использованная в тестах - мощная. Поэтому для обоих процессоров на указанных частотах в режиме 1280х1024 4AA/16AF мы получаем не "полочку", а переходную область. Но даже с учетом этого обстоятельства видно, что процессоры Sempron s754 на частоте 1600 МГц (частота младших моделей в семействе) вполне способны показать результат порядка 70 кадров/сек. Конечно, наряду с моделями Sempron с объемом кэш-памяти процессора 256 кб есть и продукты с L2-cache 128 кб. Но, как уже было показано выше, объем кэш-памяти CPU оказывает незначительное влияние на общую производительность. И даже если от приведенных на графике результатов для платформы Sempron s754 отнять еще 10%, то производительности даже самых младших моделей Sempron с частотой 1600 МГц будет достаточно для обеспечения скорости более 60 кадров/сек! Конечно, и Half-Life 2, и DOOM 3 довольно старые игры. Могут возникнуть возражения, что в современных играх Sempron все же не потянет и производительность «упрется» в мощность центрального процессора. Давайте проверим это на примере игры F.E.A.R., которая очень требовательна к ресурсам системы.

Как видите, когда мы строим «линию максимальных результатов», при одинаковой частоте CPU производительность платформы Sempron по-прежнему несколько отстает от Athlon 64 (как и должно быть), но как только мы включаем качественный режим, производительность сразу же упирается в видеокарту!

Что касается процессоров Sempron SocketAM2, то в ходе подготовки данной статьи мы не тестировали данные процессоры. Но, исходя из вышеизложенного, можно предположить - разница в производительности в 3D-играх для процессоров Athlon64 AM2 и Sempron AM2 будет еще меньше, поскольку процессоры Sempron AM2 имеют двухканальный контроллер памяти, как и процессоры Athlon64 AM2. Стоит признать, что на платформе Socket AM2 изучение влияния объема кэш-памяти процессора можно было бы провести с меньшими усилиями. Однако, как видите, и в случае сравнения платформ Socket 939 и Socket 754 нам удалось это сделать.

Не следует думать, что мы решили ограничиться только платформами Socket 939 и Socket 754. Следующая на очереди - платформа Socket AM2. Результаты, которые мы получили, хоть и были предсказаны теорией, тем не менее - впечатляют.

Мы уже попытались сравнить разные платформы, хотя и относящиеся к одному производителю и являющиеся близкими так сказать родственниками. Давайте немножко усложним задачу, и попробуем получить результаты по той же самой методике, но уже для двухъядерного процессора. В качестве такого процессора был взят Athlon 64 X2 4000 Socket AM2, штатная частота которого равна 2000 МГц. Давайте получим для него «линию максимальных результатов», точно так же, как мы делали это раньше.

И вот здесь мы видим очень интересную картину! Смотрите, на двухъядерном процессоре "линия максимальных результатов" точно совпадает с прямой линией и четко проходит через ноль! Ничего удивительного, ведь системные службы выполняются на первом ядре, а приложение (в нашем случае DOOM3) - выполняется на свободном, то есть втором ядре. Да и результаты немало возросли, хотя мы не меняли условия тестирования, в смысле настройки графики. Мы даже не пытались искать какие-либо патчи для игры, которые могли бы эффективно использовать двухъядерность CPU. Получается, что на этом графике мы видим увеличение производительности за счет второго ядра, но без всякой оптимизации игры под второе ядро CPU. Теперь мы можем дать ответ на вопрос «каков будет прирост от двухъядерности CPU в графических приложениях, неоптимизированных под многопоточность»? Ответ очевиден из графика. При той же частоте CPU прирост производительности в случае системы с двухъядерным CPU составляет от 20% до 40% по сравнению с системой на одноядерном процессоре. И это без всяких оптимизаций!

Разумеется, в нашем рассмотрении мы не собираемся ограничиться только платформами для процессоров AMD. В самое ближайшее время мы познакомим вас с результатами тестов, выполненных по нашей методике, для платформ Intel Celeron, Pentium 4, Pentium D и, конечно же - Intel Core Duo. Но об этом - в третьей части статьи. Оставайтесь с нами.

версия для печати